Scrum is not a simple thing. Many people ask me questions on different Scrum topics. I will publish my answers here.
What are the two essential features a Scrum Team should possess?
- It should choose how best to accomplish their work, rather than being directed by others outside the team
- It should have all competencies needed to accomplish the work without depending on others not part of the team
- It should use tools, processes and techniques approved by the Organization
- It should be flexible enough to complete all the work planned for the Sprint even if some team members are on vacation
Though the explanation mentions 1 &2 as the answer for this but shouldn’t option 3 also be the answer for this question. Development team should be using tools, process and techniques approved by organization and if there is any hindrance the scrum master should notice this as impediment and talk to respective stakeholders?
Mikhail: For me #3 looks like a contradiction to #1. As long as the team creates increments according to the DoD, it can use any techniques, tools, etc.
Mikhail: I think, Scaled Scrum does not prescribe any particular architecture. It only says the dependencies between teams should be minimized and we should inspect and adapt frequently. So, it is an ongoing process. Evaluating the current architecture and suggesting ways to improve it is a part of every Sprint.
As I remember, the open Scaled Scrum quiz contains only the following topics:
Q: A system is decomposed into elements like workflows, features, capabilities, etc. How it affects Scrum Teams on a scaled project?
A: It will be reflected in the implementation.
Q: Two ways how Dev Teams can ensure a good application architecture?
* Architecture is an ongoing discussion
* The DT should have a set of architecture principles and follow them
Q: How to start a big complex project?
A: Form 1-2 teams of best developers for implementing the core, add more teams later.
You see, there are no any specific architectural questions. So, nothing to read about this. 🙂
However, the exam contains references to SOA (service-oriented architecture). It is worth to get a high level view of SOA, or at least read its definition. For example at Wikipedia: https://en.wikipedia.org/wiki/Service-oriented_architecture
Mikhail: The idea is simple. All the other options are Scrum Events. Any event in Scrum is an opportunity to inspect and adapt. Sprint is not an event. It is just a time frame.
Mikhail: The Scrum Guide says: “The Development Team of the Scrum Team must define a definition of “done” appropriate for the product.” So, the correct answer is the Development Team.
From my point of view, DT owns DoD on behalf of the whole Scrum Team. So, it is possible to say “Scrum Team creates DoD”, however “Development Team creates DoD” is more precise.
Mikhail: The Product Owner is responsible for this.
In the Scrum Guide you can find that the PO is responsible for:
* Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
At the Sprint Review:
* The PO explains what Product Backlog items have been “Done” and what has not been “Done”;
* The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
The Product Owner is the Lead Facilitator of Key Stakeholder Involvement. The PO is responsible for identifying the key stakeholders for the product and involving them as necessary throughout the development effort.
Mikhail: Of course, the team can proceed. Right, PB is the single source of requirements for any changes to be made to the product. If the Scrum Team does not understand what should be done next, it means the PB needs to be refined. The Product Owner should put his product vision as backlog items, maybe with help of the Development Team.
A product backlog item should contain everything necessary to be understood by any member of the Scrum Team. So, if a new UI markup needs to be developed, it should be a part (task) of some item (story) in the PB. When the markup is ready, it should be attached to the item.
So, the answer is not a simple “yes/no”. I would carefully look at the wording of the suggested answers to be maximally close to the point I described above.
Mikhail: I would say the PO should not usually do this. The PO must be the arbiter of product value and how it is represented to the team. Frequently key stakeholders do not know exactly what they want and how it can be achieved. This is a job for the PO to understand their needs, decide how they can be fulfilled with the maximum value.
Probably, in rare cases a key stakeholder can be invited as a domain expert to a product refinement session. However, the PO should have the final word.
Mikhail: No. The Scrum Glossary gives the following definition for Product Backlog: “It is an ordered list of the work to be done in order to create, maintain and sustain a product.” So, Scrum is not specific about exactly what a Product Backlog Item is or how it should be expressed. It is just “work to be done”.
The Scrum Guide gives a bit more details about a PBI: it should have the attributes of a description, order, estimate, and value. However, it does not change the “work to be done” definition much. For example, a Product Backlog can contain knowledge acquisition tasks, prototyping, technical chores etc.
However, there is one important moment: a Product Backlog should contain items that the Product Owner cares about, in the sense that they add clear business value and can be ordered by him or her. If there are some “Developer Stories”, i.e. removing technical debt, they can be introduced by the Development Team into their own Sprint Backlog, if they think such stories are necessary in order to help mitigate a technical risk.
Mikhail: The Scrum Guide says that everyone in the Scrum Team must understand what “Done” means. So, the PO should be definitely aware of the DoD.
However, only the Development Team is in a position to define the DoD, because it asserts the quality of the work that *they* must perform.
The quality asserted must be appropriate for the Product, which implies that the PO must be consulted. Failure to consult the PO may result in an Increment not being accepted, as the DoD would not then be shared.
So, the answer is a kind of “yes”. Formally the approval is not required, but practically the DT and the PO should agree on the DoD. Otherwise the PO may not accept the Increment. For example, the PO can find that the Product is too buggy, slow, hard to use, etc.
Mikhail: The Scrum guide says:
The Product Owner is the sole person responsible for managing the Product Backlog… The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
Creation of a PBI relates to PB management. So, certainly the PO is responsible for this. However, he can delegate this work to the Development Team.
If the Scrum Master combines his role with the Developer role (the most common situation), he is a part of the Development Team and can create PBIs when it is agreed with the PO. Otherwise, I think, he should not do it.
In my quizzes I have a similar question: who can change the PB? The answer is “The PO and the DT with permission of the PO.”
Mikhail: Non-functional requirements describe qualities of the system being developed. E.g. the system should be secure, extensible and have acceptable performance. The only way to meet such requirements is to have them as a part of the DoD and check every Increment against these criteria.
From my side I would mention that if some non-functional requirements relate only to a part of the Product (i.e. to some feature), most likely the requirements should be processed as a sub-task within this feature instead of the DoD.
Mikhail: The DoD helps to reveal the work necessary to complete a PB item. So, it helps to estimate how much time it will take. With better estimations the Development Team can better plan which items can be completed in the upcoming Sprint.
Mikhail: The whole Scrum Team should come to a solution about the first Sprint length before starting it. The length of the following Sprints can be changed (adopted).
There is no a formal event for this purpose. The Scrum Guide limits only the maximum length by one month. However, the following points can be taken into account:
- The pace at which the PO wants to have increments (new features implemented), demonstrate them to the Key Stakeholders and get feedback.
- Experience of the SM. What was the optimal length for teams doing a similar work.
- Experience of the DT. Too long Sprints make planning difficult. Too short Sprints do not allow to implement bigger features in one chunk, but give faster feedback.
From my experience, the optimal Spring length is 2 weeks.
Mikhail: A first Sprint requires no more than a Product Owner, a team, and enough ideas to potentially complete a full Sprint.
Mikhail: First of all, there is no Project Manager role in Scrum. So, the manager from the question is an external person for the team.
My best options are below:
a. Invite the manager to the next Sprint Review. There the manager will see what was completed in the Sprint, what is the feedback from the Key Stakeholders, what are the priorities for the next Sprint, get some review of the timeline and budget.
b. In agile practices the duty of all participants is to be transparent. Those who need information are responsible for getting it. They have a duty to ensure that the information they act on is obtained in a timely fashion and with minimal filtering.
So, the manager can investigate the artifacts of the Scrum Team: the Product Backlog, the Sprint Backlog, the Increment. The team is responsible for sharing these artifacts and any information radiators that can help to make the artifacts more transparent (e.g. burn down charts, story boards, etc.)
One more point is that proper use of Scrum makes sure that the most valuable features are implemented first and the proof of success lies in ongoing delivery and not in reporting.
Mikhail: The most important individuals for maximizing value for the Product are the Key Stakeholders. The PO should identify and involve them as necessary throughout the development effort. The Key Stakeholders are typically customers, purchasers, users, and the people that fund the product’s development. These people may be internal or external to the Organization.
Mikhail: The PO can delegate writing user stories.
It is a Product Backlog managing activity. Who does the work of updating and managing the Product Backlog is a collaboration between the Product Owner and the Development Team. However, the Product Owner is solely responsible and accountable for the decisions in the Product Backlog.
So, ordering PB is the solely responsibility of the PO.
The Scrum Master is responsible for facilitating Scrum events.
Mikhail: There are several possible good answers. I would suggest the PO should focus on:
* Key Stakeholder Involvement
In order to maximize value, the PO should identify the key stakeholders for the product, and involve them as necessary throughout the development effort.
* Product Marketplace
The Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized.
* Product Release Decisions
The PO is the one and only person who can decide whether to release the latest increment of the Product. In order for value to actually be captured, a release of the product must occur.
Mikhail: Of course not. This question is very similar to the question #17 above.
Who does the work of updating and managing the Product Backlog is a collaboration between the Product Owner and the Development Team. However, the Product Owner is solely responsible and accountable for the decisions in the Product Backlog.
For example, the PO can write nothing, but explain everything in detail to the Development Team. Then the team will create the required PB items and write down all the details.
- A. Writing clear, transparent User Stories
- B. Working with customers and stakeholders to identify the most important product requirements
- C. Being with the Scrum team all the time, just in case they need me to clarify a requirement
- D. Clearly communicating project or release status and strategies to customers and stakeholders
- C is wrong because the PO does not have to spend all the time with the DT. The PO has other things to do. For example, communicating with Key Stakeholders. The main PO commitment is product value delivery. So, he or she should spend enough time (but not all the time) with the DT to meet that commitment.
- A is just partially right. Writing clear user stories is important, but the Product Backlog also contains many other things like features, functions, requirements, enhancements, etc. The PO is responsible for the whole management of the Product Backlog. Also the PO can ask the DT to write the stories.
- D is partially correct because the PO should communicate his product vision not only to the Key Stakeholders, but also to the Scrum Team.
- B is correct. Identifying the most valuable Product features one of the most important PO responsibilities.
- So, I would answer B and D.
I think, in the broad sense the answer is “yes”. The PB is the source for the Sprint Backlog. The Sprint Backlog is the source of the Dev Team work. However, only the Dev Team knows how to implement Sprint Backlog Items. It can involve technical tasks, for example, removing some technical debt or even installing a development environment for a new developer.
The Scrum Guide says: the SM helps the PO to understand and practice agility. Agility means using the most effective ways to collaborate. Direct collaboration between the PO and the DT is the most effective one. So, the best technique for SM is to monitor communications between the DT and the PO and facilitate direct collaboration.
No. It is just one of the first steps to success. Success in Scrum is getting maximum value with the existing resources. Value, as defined in a Scrum context, is the financial (or social) benefit an organization receives or might receive by creating and releasing the product under development. In order for value to actually be captured, a release of the product must occur. The sooner you release, the sooner you can start capturing the value created by the product.
Increase in team’s velocity shows that the Dev Team became more mature and can do more in the same time frame.
The Scrum Guide says: During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.
So, the answer is “the Scrum Team and stakeholders”.
A) Its productivity is likely to stay the same
B) Its productivity is likely to increase
C) Its productivity is likely to decrease
In a short term the productivity will decrease because the new teams will spend time to get up to speed with the Product. The old team will spend a lot of time for communications with the new teams.
A) The frequency at which team formation can be changed
B) The organization has mandated similar length sprints
C) The risk of being disconnected from the stakeholders
D) The level of uncertainty over the technology to be used
E) The ability to go to market with a product release.
Mikhail: C, D, E.
A. is wrong because Development Teams in Scrum are self-organizing and can decide to change at any time.
B. is bad because Organization is not responsible for the Sprint length. It is determined by the Scrum Team. The PO and the Dev Team should agree on this. The SM may have some coaching duties to perform in that regard.
C. is good because the bigger part of interaction with the Key Stakeholders happens at the Sprint Review meeting. If the Sprint length is bigger, this feedback loop becomes longer.
D. Shorter Sprints is an effective way to hone in on the requirements or try out the technology before committing to a solution.
E. Shorter Sprints suppose that the Dev Team produces “done” increments more frequently. It allows the PO to release the increments more frequently too.
A) Manger would divide them depending on location, bonding between members and xyz…
B) Developers will form teams themselves.
C) Scrum master will assign them according to budget.
D) Understanding scrum encourage self organization, developers will organize themselves into teams based on skills.
E) Product owner brings all developer working on same product together for planning and depending on functionalities , developer with self organize themselves into teams.
Mikhail: All the options related to self-organization are correct: B, D and E.
Mikhail: Of course the answer is “True”. The PO comes to the Sprint Planning with an idea for the Sprint Goal and then all the Scrum Team crafts the final version of the Goal.
A) The scrum process and how it was used during the Sprint
B) Coding and Engineering practices
C) Sprint Results
D) All of the above
Mikhail: The Scrum Guide says “A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.”
So, D. option would be great for the Sprint Retrospective meeting, but it is wrong for this question. All the topics related to the development process are discussed at the Sprint Retrospective.
So, the correct answer for this question is C. Sprint Results.