--------------------------DE-TOUR--------------------------
In this chapter, the following are included for clarity and context. They are not part of The Scrum Guide:
Staffing plan, Project Management aspects, Upfront architecture, Definition of "Ready,” Spike
--------------------------DE-TOUR--------------------------
Scrum is a container framework with a focus on collaboration within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value. Building a product using Scrum is a discovery process that starts with just enough preparation. This may sound odd to those who have planned “Projects in traditional methods.” In a traditional approach, a lot of preparation is required before the team starts the development work.
Traditionally, the Project Manager needs to forecast the budget, schedule, staffing plan, risk management plan, quality plan, and communication plan based on the project scope.
Scrum does not take such an approach. It does not attach value to plans and artifacts that are based on long-term assumptions. It starts with just enough preparation and pursues a “value discovery and maximization” journey. Therefore, Scrum is a journey and cannot be called a “Project” in the traditional sense.
What is the input to the first Sprint?
The inputs to the first Sprint are the Product Backlog and projected Sprint capacity of the Development Team. The Product Backlog may contain only the initial business ideas. The projected capacity of the team is only a guess at this point. It will be refined over the upcoming Sprints as clarity emerges based on past performance.
Fig. 11 shows the lifecycle of Scrum. The journey starts with “just enough preparation.” The journey concludes when enough value is delivered, the investment becomes unjustified, or when allocated resources are exhausted.
Fig. 11- Starting Scrum - Inputs to the Sprint
-------------------Question- 1--------------------------
Select all that apply. Before starting the first Sprint, what needs to be in place?
a) A complete Product Backlog capturing detailed product needs.
b) Availability of the Project Manager.
c) Just enough Product Backlog Items with business ideas for the first Sprint.
d) Completed System Architecture.
e) Staffed Scrum Team.
-------Answer-------
There are no preconditions for the first Sprint. The availability of a Scrum Team and a list of business ideas for the first Sprint are enough to start the Sprint. Correct answers are ‘c’ and ‘e.’
-------------------Question- 1--------------------------
What about the input to subsequent Sprints?
Apart from the first Sprint, every other Sprint has more input to Sprint Planning. In addition to the Product Backlog and projected Sprint capacity of the Development Team, the additional inputs to Sprint Planning include the latest product Increment and the past performance of the Development Team.
How to staff without a staffing plan?
Traditional Projects bring people to the work and manage staffing complexities: In ‘traditional projects,’ the Project Manager produces a staffing plan based on the predicted work. This staffing plan projects the volume of work on a timescale, e.g. weekly or monthly. Using this projection, the “human resources” are brought to the work and removed when the work is complete.
The Project Manager manages and controls the complexities associated with maintaining this projection, forecasting the resource expenditure, and monitoring the full utilization of the resources.
Scrum brings the work to a constant team and avoids staffing complexities: The Scrum Team is an appropriately sized team with 3 – 9 Developers, a Product Owner, and a Scrum Master. Before the Sprint starts, this team is staffed with all three roles. The Development Team is staffed such that it has all the skills needed to create the Product Increment.
Once a Scrum Team is staffed, the team is maintained as a constant talent pool that is available throughout the journey. After establishing the constant team, Scrum facilitates ‘bringing the work to this team.’ The Product Owner brings the work, and the Development Team maps their availability to do the best-valued work. This self-organization of the team eliminates the necessity for any manager to map their work.
There could be an occasional churn of team members going out and replacements coming in. There may be occasions where the team identifies a lack of some skills and will induct more developers with those skills.
So, other than the initial staffing and ongoing adjustments to maintain it, there is no need for an exclusive staffing plan.
-------------------Question- 2--------------------------
When a Scrum Team adds new team members to replace outgoing members, the productivity of the team
a) Will be negatively impacted.
b) Will be positively impacted.
c) Will remain the same.
-------Answer-------
When new team members join, the productivity of the team will be temporarily reduced. Correct answer is ‘a.’
-------------------Question- 2--------------------------
What about other management aspects such as Scope, Quality, Risk, Communication, etc.?
All of these aspects are owned, managed, and controlled within Scrum. However, there is no exclusive project management plan or person who manages it. These project management activities are distributed among the three Scrum roles.
Product Scope, Budget, and Schedule: The Product Owner manages the product scope in terms of the Product Backlog. They also manage the cost benefit of the product features. The cost of the work does not fluctuate as Scrum has a constant team. So, it is the Product Owner’s responsibility to put together the features such that maximum value is obtained from this constantly available team. The Product Owner keeps the estimated time updated on the incomplete features. Keeping this up to date is important to forecast the schedule and completion timelines.
Quality Plan: The Scrum Team as a whole owns the quality of the Increment. The expected functional quality is specified in the tests. The expected technical quality is made transparent by the definition of “Done.” The Scrum Team ensures the following rules:
• During a Sprint, the quality goals do not decrease.
• During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.
• As a Scrum Team matures, it is expected that their definition of “Done” will expand to include more stringent criteria for higher quality.
Risk Plan: The Scrum framework is fundamentally a risk reduction framework. It reduces the risk of big commitments, accumulation of waste, hidden weaknesses in product development abilities, etc. by limiting the planning horizon to shorter periods of time. Sprints enable predictability by ensuring inspection and adaptation of progress towards a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost. Any other ongoing risks such as potential undone work are publicly communicated via impediments and acted upon by the team.
Communication Plan: Scrum defines clear boundaries for communication to increase the transparency and focus on valuable work.
The Product Owner is the single point of communication for stakeholders including customers, users, and management on product-related items. The Scrum Master manages the communication at the periphery of the team, such as multiple departments of the organization vs. the Development Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Within the Scrum Team, the communication is continuous. It is achieved by the transparency of information through artifacts. These artifacts provide necessary information about the product plan, work pipeline, current completion status, etc. Scrum events enhance the communication. In particular, Daily Scrums improve communication, eliminate other meetings, identify impediments to development, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
Standards such as definition of “Done,” definition of “Ready,” coding standards, etc. establish the same understanding to all stakeholders about the expected work.
How can development start without an architecture or design?
Traditional projects create an upfront design: Traditionally, the entire technical design is created before development begins. This design is based on the current understanding of the business needs and technical solution patterns used in the past.
Development Teams emerge the design throughout the journey: Development Teams do not create a big upfront design before they start Sprints. Instead they evolve the design.
• You may recollect that the Product Backlog Items are refined in the Product Backlog Refinement sessions ahead of Sprints. The items are refined until they are transparent enough to estimate and confirm that they can be “Done” within a Sprint. To find the work estimate, the Development Teams needs to visualize at least a simple skeleton design.
• In the Sprint Planning, this skeleton design is revisited and evolved to a finer level.
• Further, the Development Team usually chooses to set aside core design hours during the Sprint. As they get more clarity during the work, they evolve the best designs through continuous refactoring of initial designs.
• When some design patterns appear repeatedly throughout the Sprints, those patterns are ‘locked in.’ Most likely, such patterns may become the pillars of that system architecture.
As stated earlier, Scrum is a container framework within which Scrum Teams can employ domain-specific engineering techniques. The guideline above is one approach under the concept of “Design Emergence.” Many teams also follow other variations. The skills required to emerge the design through constant refactoring is a separate subject.
-------------------Question- 3--------------------------
Select all that apply. In Scrum, the technical design of the solution is
a) Built one module after another with the Architect’s guidance.
b) Initially created as a common architectural pattern by selected designers and architects and shared with others to build on top of it.
c) Started with just enough design which emerges throughout the Sprints.
d) Reached through focused attention during core design hours in the Sprint.
-------Answer-------
There is no Designer or Architect role in Scrum. Correct answers are ‘c’ and ‘d.’
-------------------Question- 3--------------------------
How can the Scrum Team prepare enough Product Backlog Items before the first Sprint?
While there are a couple of ways to come up with an initial Product Backlog, it is not mandatory to have any minimum criteria for the Product Backlog before the first Sprint starts. All that is required for the first Sprint to start is a staffed Scrum Team and a set of business ideas to deliver in the first Sprint.
Approach I - A Scrum Team can initially work outside the Scrum Sprints to create and refine just enough of a Product Backlog to start. It should be made transparent to stakeholders that this activity does not lead to any opportunity of inspecting a useful outcome. Since this activity does not create working functionality, this activity should not be incorrectly called a Sprint. The time taken to arrive at this type of Product Backlog should be as minimal as possible.
Approach II - Start the Sprint Planning and refine just enough Product Backlog Items for the first Sprint. The team can craft the Sprint Goal, and then come up with a work plan for the initial days of the Sprint.
Once the Sprint is in motion, the Product Backlog Items are further refined in the Product Backlog Refinement sessions during the Sprint, so that there will always be some refined items ahead of future Sprints.
-------------------Question- 4--------------------------
A Scrum Team can have an exclusive first Sprint to prepare a Product Backlog, which is the sole outcome from that Sprint.
a) True
b) False
-------Answer-------
A Scrum Team can initially work outside the Scrum Sprints to create and refine just enough of a Product Backlog so that the first Sprint can start. However, this initial effort should not be called a Sprint. Also, it should only take a few days. Correct answer is 'b.'
-------------------Question- 4--------------------------
There is no Sprint Zero or Iteration Zero before the first Sprint
Every Sprint must produce potentially useable business functionality. Some teams create Sprint Zero for preparing a Product Backlog and other upfront preparation including tasks such as setting up the work environment, configuring tools, etc.
Sprint Zero does not produce any useable functionality. If there is no useable functionality, there is no opportunity for feedback on inspection and adaptation. Without the feedback, we will not know if the investment in the concluded Sprint was justified or not. This resembles a waterfall way of working.
Scrum is immutable. The essence of Scrum is lost when Scrum is customized to include a Sprint Zero.
The inability of Scrum Teams to get the development work started immediately indicates weaknesses in the way that organization works today. When Scrum is newly applied, it makes the existing weaknesses in the organization transparent. That is the strength of Scrum and organizations should leverage the transparency that Scrum brings in. Organizations should commit to improve the identified weaknesses. Only then will the truly self-organized teams emerge.
Making exceptions to weaknesses, in this case Sprint Zero, will hide the opportunities for improvements. The status quo will continue.
Another example is that some teams will create an exclusive Sprint called the “hardening Sprint” to enhance the technical quality of the Product Increment to make it production ready. Instead of looking at the situation by asking the right question “Why is the team not able to produce a production-quality Product Increment in the original Sprint itself?” this weakness is hidden under disguise of false Scrum terminology such as “hardening Sprint.”
The Ongoing Act of Product Backlog Refinement – Starts before the first Sprint and continues
Purpose: The Product Owner and Development Team continuously refine the Product Backlog Items. The items are refined until they are transparent enough for the Development Team to estimate and confirm that they can be “Done” within a Sprint. When a Product Backlog Item reaches this level of transparency, it is also known as “Ready.” The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it to understand and select trade-offs, but the people who will perform the work make the final estimate.
The definition of "Ready” is a shared understanding by the Product Owner and the Development Team regarding how much clarity the Product Backlog Items should have before they are introduced at Sprint Planning.
A Scrum Team should not wait until Sprint Planning to refine the items in a “just in time” manner. It is good practice to have a sufficient number of items in a “Ready” state for at least one or two upcoming Sprints.
When: Backlog Refinement starts before the first Sprint and goes on throughout all Sprints. The Scrum Team decides how and when refinement is done. However, Product Backlog Items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Timeline: This is probably the only activity in the Sprint where the Development Team performs work outside the current Sprint Goal. Because it is important to ensure that there will always be some “Ready” items that can be selected for the next Sprint.
But care should be taken to optimize the time which the team spends on this act. Though this is not a time-boxed activity, Refinement usually consumes no more than 10% of the capacity of the Development Team.
What is achieved: Product Backlog Items are decomposed by analyzing their intent. Each item is added with a description, order, estimate, and value. Higher-order Product Backlog Items are usually clearer and more detailed than lower-order ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail.
-------------------Question- 5--------------------------
In Backlog Refinement sessions, the Development Team performs development activities such as coding and testing.
a) True
b) False
-------Answer-------
The Development Team helps in refining the items to a level such that the team can complete the items to "Done" within a Sprint. They do this by analyzing, putting together solutions/designs, decomposing, and adding details, but there is no technical development activity during this refining session. Correct answer is ‘b.’
-------------------Question- 5--------------------------
--------------------------DE-TOUR--------------------------
Spike: During the Product Backlog Refinement, a Team can perform technical analysis or design to understand the work involved. In situations where there is less clarity to estimate the effort and in-depth technical analysis or development (coding) is needed, the team can go for a “Spike” with the consensus of the Product Owner. A Spike is a time-boxed research activity to prove or disprove something and gain more clarity. Note that the time for Backlog Refinement including any Spike should not exceed 10% of the Development Team’s time. The term 'Spike' is not part of the Scrum definition.
--------------------------DE-TOUR--------------------------
Backlog Refinement produces: Product Backlog
Content: A Product Backlog contains an ordered list of Product Backlog Items, each one having a description, order, estimate, and value. The Product Backlog Items together represent all that is needed in the product. The items include features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. It is the single source of requirements for any changes to be made to the product.
Purpose: To maximize the transparency of what is required for the product, the order the team will work on next, and the estimate of the work involved.
Owner: The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Format: Nothing specific, but each item must have a description, order, estimate, and value. Usually the higher-order Product Backlog Items are clearer and more detailed than lower-order ones.
Lifecycle: A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs in order to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists. As a product is used and gains value and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes to the Product Backlog.
Fig 12- Sample of Product Backlog
-------------------Question- 6--------------------------
What causes a change to the Product Backlog?
a) The Product Backlog cannot be changed without a change request to the Product Owner.
b) The Product Backlog is not updated when a Sprint is in progress. Changes to team size and estimations may cause changes in the Product Backlog.
c) The Product Backlog can be updated anytime by the Product Owner. Changes in business requirements, market conditions, or technology may cause changes to the Product Backlog.
-------Answer-------
Correct answer is ‘c.’
-------------------Question- 6--------------------------
Defining the definition of “Done,” which can provide clarity on the required work standard
We have already discussed how the definition of “Done” provides a common understanding to the Scrum Team members about what it means for the work to be complete.
In addition to being a standard for measuring completion, the definition of “Done” is a reminder to the Development Team about the need to account for all the end-to-end work required to meet the conditions. Teams can use this information to find out how many items they can select during Sprint Planning.
Who defines the definition of "Done"?
If the Scrum Team is going to work on an existing Product or System, there should be an existing definition of "Done" that is a standard for any work performed on this Product or System. The team should start with that.
If the definition of "Done" for an Increment is part of a development organization’s conventions, standards, or guidelines, all Scrum Teams must follow that as a minimum.
If there is no existing definition of "Done," the Development Team must define the definition of “Done” as appropriate for the product.
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.
What if multiple Scrum Teams are working on the same Product?
If there are multiple Scrum Teams working on a system or product release, the Development Teams on all of the Scrum Teams must mutually define the definition of “Done.” Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. It is not necessary for the definition of “Done” to be the same but a mutually defined definition of “Done” should enable the combined Increments to be potentially releasable.
Should the Product Owner approve the definition of "Done"?
The Development Team defines the definition of "Done." It is essential for the entire Scrum Team including the Product Owner to be well aware of the definition. However, there is no need for approval from the Product Owner.
While the Product Owner needs to be involved and made to understand the conditions, it is the Development Team’s responsibility to define the conditions in a verifiable way because many of these conditions are usually about technical quality. For example, the Product Owner may want a condition such as “The Increment should be thoroughly tested because it will be released to production,” and the Development Team may define it as “The Increment should pass all the automated unit tests with 95% code coverage.”
Can new teams define a relatively easy definition of "Done"?
The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.” Development Teams deliver an Increment with product functionality every Sprint. This Increment is useable, so the Product Owner may choose to immediately release it.
The definition of “Done” should not be set with the objective of making it easy to meet but failing to qualify for production. Unless the Increment is potentially releasable, the Scrum Team cannot get feedback from actual usage. Diluting the definition of “Done” will hide the current weaknesses in Product Development.
Given this, even a new team should define it such that the Increment will be production fit. However, the definition should contain conditions that are realistic to motivate the team. Then it can be continually improved by the maturing team's ability to perform all that is required. Having a realistic definition of “Done” for a new team means that the working Increment may have known bugs, but they are transparent between the Development Team and Product Owner.
The total budget and number of Sprints are decided in which event?
Parameters like timelines and budget are reviewed in the Sprint Review. Work standards like definition of "Done" are reviewed in the Sprint Retrospective. However, Scrum does not clarify when these parameters are decided for the first time. Unless otherwise inferred through the question, it is safe to assume that they are defined before the first Sprint at the time when just enough of a Product Backlog is put together.
Rules:
• Only the Product Owner can finalize what can be added to the Product Backlog.
• If multiple Scrum Teams work together on the same product, only one Product Backlog is used to describe the upcoming work on the product. An attribute that groups the items by each team may then be employed.
• Estimating Product Backlog Items: Only the people that will do the development work on the Product Backlog Items, i.e. the Development Team, can finalize the estimates. Estimating the Product Backlog Items is a continuous process through the ongoing act of Backlog Refinement. This estimation is done by the Development Team after the Product Owner’s input.
• Measuring the value of the Product Backlog Items: It is mandatory for the Product Owner to assign a value for each Product Backlog Item. However, Scrum does not prescribe any technique to measure the business value of the Product Backlog Items. The Product Owner may use one or more appropriate techniques in the industry to estimate the business value.
• Ordering the Product Backlog Items – based on collective value: The Product Backlog Items must be ordered. However, though it is generally ordered based on the relative value of individual items, it is not necessarily a hard rule. It is based on the criteria which are deemed most appropriate by the Product Owner in order to maximize the collective value of the Product and the Development Team’s work. In addition to ordering by the business values, the Product Owner can consider other factors like cost, risk, coherence, organizational policies, and also can seek the input of the Development Team about the technical dependencies between the Product Backlog Items. The Product Owner shall try to optimize the ordering such that it eventually leads to the product Increment with the best overall value that is both releasable and useable.
-------------------Question- 7--------------------------
Which of the following statements is not correct?
a) Only the people who perform the work can finalize the estimate of Product Backlog Items.
b) The Product Owner always orders the Product Backlog Items based solely on the value of each individual item compared to another item.
c) Multiple Development Teams working on the same product should have only one common Product Backlog.
d) A Scrum Master can author a Product Backlog Item for the Product Owner's consideration.
e) The Development Team finalizes all estimates.
-------Answer-------
The Product Owner is the ultimate authority of finalizing what needs to be added to the Product Backlog. However, they can have others provide them with suggestions. So, a Scrum Master can always author an item for the Product Owner’s consideration. The Product Owner strives to maximize the collective value of the Product and the Development Team’s work. To achieve that, they can choose to follow any appropriate logic for ordering. It need not always be the individual business value. Correct answer is ‘b.’
-------------------Question- 7--------------------------
The logic behind which parameter is chosen to order the Product Backlog is bit tricky. Go through the following questions to understand the best choice for a given context.
-------------------Question- 8--------------------------
The Product Backlog is ordered by
a) The individual Product Backlog Item's value.
b) Whatever increases the overall value of the team's work.
c) Whatever is deemed as appropriate by the Product Owner.
-------Answer-------
A clear answer is there. Correct answer is 'c.'
-------------------Question- 8--------------------------
-------------------Question- 9--------------------------
The Product Backlog is ordered by
a) The individual Product Backlog Item's value.
b) Whatever increases the overall value of the team's work.
c) The priority of senior management.
-------Answer-------
There is no clear answer. Choose the next best choice. Correct answer is 'b.'
-------------------Question- 9--------------------------
-------------------Question- 10--------------------------
The Product Backlog is ordered by
a) The individual Product Backlog Item's value.
b) Whatever is deemed appropriate by technical and domain experts.
c) The priority of senior management.
-------Answer-------
There is no clear answer. Choose the next best choice. Correct answer is 'a.'
-------------------Question- 10--------------------------
Summary
• Scrum starts with just enough preparation and pursues a “value discovery and maximization” journey.
• The journey is concluded when enough value is delivered or when the investment becomes unjustified or when allocated resources are exhausted.
• The Sprint is the heart of Scrum. It is like a mini project.
• A Sprint enables predictability by ensuring inspection and adaptation of progress towards a Sprint Goal at least every calendar month.
• Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.
• Unlike the traditional approach of bringing people to the work, Scrum brings the work to the people. It is staffed with a constant team which avoids staffing complexities.
• Unlike the traditional approach of big upfront design, the Development Teams evolve the technical design throughout the journey.
• Unlike the traditional approach of an upfront complete requirements specification, a Scrum Team starts the first Sprint with just enough Product Backlog.
• The Product Backlog is an ordered list of everything that may be needed in the product and is the single source of requirements for any changes to be made to the product.
• The first Sprint needs just enough Product Backlog that only lays out the initially known and best-understood requirements. The Product Backlog is a living artifact that evolves and constantly changes to identify what the product needs in order to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.
• Product Backlog refinement is the ongoing act of the Product Owner and Development Team collaboratively adding detail, estimates, order, and value to items in the Product Backlog.
• Refinement starts before the first Sprint and goes on through all the Sprints, but consuming no more than 10% of the capacity of the Development Team.
• The Product Owner orders the Product Backlog Items by whatever method they think is the most appropriate to maximize the value of the product.
• Only the Development Team can finalize the estimates of Product Backlog Items.
• A Sprint starts with the Sprint Planning event.
• The input to this meeting is the Product Backlog, latest product Increment if any, projected capacity of the Development Team during the Sprint, and past performance of the Development Team if available.
