In one of our previous posts, we explained why Scrum Teams must create Done Increments in order to get a benefit from using Scrum. In this post, we'd like to dive a little deeper on what an Increment actually is.
"An Increment is a concrete stepping stone towards the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable." – Scrum Guide1 The term Increment can be confusing, especially to people who are new to Scrum or agile product development. To make this easier to understand, let's borrow a concept from software that we're all familiar with: versions. An Increment is the latest stable version of a product. "Latest" means that a product is being developed incrementally, with each Increment being an attempt to be more valuable than the previous one, for example through better functionality. "Stable" means that every Increment meets the Definition of Done and is usable by users. An Increment is the latest stable version of their product that is usable by the users. Let's look at some examples of Increments.
Here are some examples of Increments of various products:
Now, let's come up with some examples that aren't Increments:
These things aren't usable by or valuable for users. And you can't manage the 3 key-risks of product development through these things. Hence they can't be Increments.
The first Increment should be created right within the first Sprint in order to manage product development key-risks, especially the feasibility risk of the Scrum Team. This also prevents the Scrum Team from the fallacy of a "Sprint Zero" (to create the Product Backlog, the release plan, and the architecture) and the fallacy of "phased Sprints" (some Sprints to analyze, some Sprints to specify, some Sprints to build, ...). These two common misconceptions won't help use empiricism to create value and manage risks. The first Increment should be created right within the first Sprint. Some Scrum Teams and organizations that are not that experienced with Scrum say that a Scrum Team can't create an Increment during their first Sprint(s) as they will first have to create the product foundation or product architecture. While it's often necessary to spend a lot of time on creating a minimal foundation during early Sprints, a Scrum Team needs to create at least one feature every Sprint.
"Multiple Increments may be created within a Sprint. [...] Work cannot be considered part of an Increment unless it meets the Definition of Done." – Scrum Guide In order to manage the 3 key-risks of product development, Developers on a Scrum Team create at least one Increment per Sprint. They can, however, create many Increments within a Sprint, each Increment being an update of the previous Increment. Here's what this looks like:
While Developers create Increments, it's the Product Owner who decides when to deliver an Increment to users. Being accountable for that decision is essential, so the Product Owner can maximize the value of the product. The Product Owner can decide to deliver a single or multiple Increments per Sprint or decide to wait several Sprints, depending on her strategy to maximize value and manage the 3 key-risks of product development. When the Product Owner decides to deliver the Increment, it's important that it can be delivered to users without further effort. Everything else would cause a delay in time-to-market, potentially resulting in a lost opportunity to maximize product value.
"The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals." – Scrum Guide The work of a Scrum Team and their Developers can be broadly divided into three areas:
As part of discovering value, a Scrum Team and their Developers seek to learn more about the users, their needs and ways to create value. Their discovery work – for example, user research, competitor analysis, ideation, creating and validating hypotheses – might not become part of an Increment directly but helps the Scrum Team create and deliver valuable Increments as a result. Regarding the delivery of value, the Developers create and deliver Increments. Their work in this area – for example, designing, building and testing a product feature or improving the product quality by removing technical debt – directly results in a new Increment. To improve their effectiveness, a Scrum Team "identifies the most helpful changes" during a Sprint Retrospective. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint."1 These improvements might result in work for the Developers that doesn't add to an Increment directly but will help them become more effective in creating Increments. So, a Scrum Team can do work that doesn't result in an Increment directly, however, all their work should focus on the Product Goal and Sprint Goal in order to maximize value.
When multiple Scrum Teams work together to create a product, they create integrated Increments. This means that the work of all individual Scrum Teams is combined into an integrated Increment. If the Scrum Teams use the Nexus framework to scale Scrum, the Nexus Integration Team (NIT) is accountable that the Scrum Teams create an integrated Increment at least once every Sprint. Here's an example of what this might look like with three Scrum Teams in a Nexus:
Do you need help creating Increments regularly and delivering them to users earlier in order to manage your key-risks of product development? We help Scrum Teams create and deliver digital and physical products through Increments. So, let's talk. Let's talk!
References:
The Actual Exam Version included actual exam questions verified by IT Experts. We verified questions and updated frequently each month and also based on members’ feedback to keep updating with the real exam. We are offering money back immediately if questions in our Actual Exam Version do not appear in your exam. Highly recommend you take the Actual Exam Version then go to the exam as soon as possible.
QUESTION NO: 1 A. Yes, but only for Scrum Teams whose work has dependencies. B. Yes, otherwise the Product Owners (and stakeholders) may not be able to accurately inspect what is done. C. No, each Scrum Team stands alone. D. No, that is far too hard and must be done in a hardening Sprint. QUESTION NO: 2 A. It can’t. Only Product Owners can cancel Sprints. B. When functional expectations are not well understood. C. When the Product Owner is absent too often. D. When the selected Product Backlog items for the Sprint become unachievable. E. When a technical dependency cannot be resolved. QUESTION NO: 3 A. The Sprint Backlog. B. The Sprint Goal C. The release plan. D. Sprint Review minutes. QUESTION NO: 4 A. Ensure every Increment meets them. B. Make sure the release department understands these requirements, but it is not the Development Team’s responsibility. C. Handle them during the Integration Sprint preceding the Release Sprint. D. Assign them to the lead developers on the team. QUESTION NO: 5 A. When the Product Owner says it is done. B. When all Product Backlog items meet their definition of “Done”. C. When all the tasks are completed. D. When the time-box expires. QUESTION NO: 6 A. True QUESTION NO: 7 A. Put them on a separate list on the Scrum board, available for all to see. B. Add them to the Product Backlog to ensure transparency. C. Run the integration and regression tests before the end of the Sprint, and capture the open work for the Sprint Backlog of the next Sprint. D. Add them to the definition of “Done” so the work is taken care of every Sprint. QUESTION NO: 8 A. The break between Sprints is time-boxed to 1 week for 30 day Sprints, and usually less for shorter sprints. B. Enough time for the requirements for the next Sprint to be determined and documented. C. Enough time for the Development team to finish the testing from the last Sprint. D. None. A new Sprint starts immediately following the end of the previous Sprint. E. All of the above are allowed depending on the situation. QUESTION NO: 9 A. Cancel the Sprint. Send the entire team to an advanced Scrum training and then start a new Sprint. B. Forecast the most likely Product Backlog items to meet the goal and create a Sprint Backlog based on a likely initial design and plan. Once the time-box for the Sprint Planning meeting is over, start the Sprint and continue to analyze, decompose, and create additional functionality during the Sprint. C. Continue the Sprint Planning meeting past its time-box until an adequate number of Product Backlog items are well enough understood for the Development Team to make a complete forecast. Then start the Sprint. D. Discuss in the upcoming Sprint Retrospective why this happened and what changes will make it less likely to recur. E. Ask everyone to take as much time as needed to analyze the Product Backlog first, and then reconvene another Sprint Planning meeting. QUESTION NO: 10 A. What to do and who will do it. B. How conditions have changed and how the Product Backlog should evolve. C. What can be done and how to do it. D. What went wrong in the last Sprint and what to do differently this Sprint. E. Who is on the team and what team member roles will be. QUESTION NO: 11 A. Sprint Retrospective. B. Members must be stand up at the Daily Scrum. C. Sprint Burndown Chart. D. Release planning. E. All of the above. QUESTION NO: 12 A. To take time to judge the validity of the project. B. To inspect the product Increment with the stakeholders and collect feedback on next steps. C. To review the Scrum Team’s activities and processes during the Sprint. D. To build a team sprint. QUESTION NO: 13 A. The Project Manager. B. The Development Team. C. The Scrum Team. D. The Product Owner. QUESTION NO: 14 A. The Scrum Master and Product Owner. B. The Development Team. C. The Development Team and Product Owner. D. The Scrum Team. E. The Development Team and Scrum Master. QUESTION NO: 15 A. At the Sprint planning meeting. B. During the Daily Scrum. C. Never. All Sprint Backlog Items are “owned” by the entire Scrum Team. D. Whenever a team member can accommodate more work. QUESTION NO: 16 A. True QUESTION NO: 17 A. The Scrum Master as he/she is responsible for the Development Team’s productivity. B. The Scrum Team, in a collaborative effort where the result is the common denominator of all members’ definition. C. The Product Owner as he/she is responsible for the product’s success. D. The development organization (or Development Team if none is available from the development organization). QUESTION NO: 18 A. Teach the Product Owner to work with the lead developers on ordering Product Backlog in a way to avoid too much technical and development overlap during a Sprint. B. each them that it is their responsibility to work with the other teams to create an integrated Increment that is inclusive of all five team’s work. C. Collect the Sprint tasks from the teams at the end of their Sprint Planning and merge that into a consolidated plan for the entire Sprint. D. Visit the five teams each day to inspect that their Sprint Backlogs are aligned. QUESTION NO: 19 A. Make up a plan for the rest of the project. B. Analyze, describe, and document the requirements for the subsequent Sprints. C. Develop at least one piece of functionality. D. Analyze, design, and describe the complete architecture and infrastructure. E. Create an increment of potentially releasable software. QUESTION NO: 20 A. By not allowing documentation. B. By the Development Team deciding what work to do in a Sprint. C. By preventing stakeholders from entering the development room. D. By removing titles for Development Team members. E. By being a lightweight framework. What’s next? |
When multiple Scrum teams are working on the same product should all of their increments be integrated in every Sprint?
zusammenhängende Posts
Urheberrechte © © 2024 frojeostern Inc.
