The Product Owner’s responsibilities in the various Scrum processes and this course will take you through this in more details: Create Product Vision Defines the Product Vision Identi
Working with HR on formation of the Scrum Team Just as in other projects, we normally have to go through the HR department to obtain
If you are a Product Owner you will have to go through the normal administrative processes in the company to assemble your Team This involves some or all of the below Tasks or some other process:
Identifying People Requirements is one of the initial steps in selecting the Scrum Master and the Stakeholder(s) It is important to document the roles and responsibilities of all those who will be involved in completing the Tasks in the project This includes all individuals involved in the project in any capacity, regardless of whether their role is core or non-core
Usually, the Product Owner or the Scrum Master work with the Human Resource Department of the company to determine and finalize the People Requirements for a project
Prior to selecting the Scrum Master and Stakeholder(s), their availability must be confirmed
Only Team members who will be available and can fully commit to the project should be selected People Availability and Commitment are commonly depicted in the form of calendars showing when human resources will be available to work throughout the duration of the project
To be effective, Scrum Teams should ideally have six to ten members; and replacing persons or changing Team members is not advisable in Scrum Core Teams Therefore, it is important to have persons in the Scrum Core Team who are available and fully committed to the project
The Organizational Resource Matrix is a hierarchical depiction that combines a functional organizational structure and a project organizational structure Matrix organizations bring together Team members for a project from different functional departments such as information technology, finance, marketing, sales, manufacturing, and other departments, and create cross-functional Teams
Team members in a matrix organization fulfill two objectives—functional and project Team members are directed by Product Owner(s) with respect to project related activities, while the functional managers perform managerial activities related to their departments such as performance appraisals and approving leaves
The Skills Requirement Matrix, also known as a competency framework, is used to assess skill gaps and training requirements for Team members A skills matrix maps the skills, capabilities, and interest level of Team members in using those skills and capabilities on a project Using this matrix, the organization can assess any skill gaps in Team members and identify the employees who will need further training in a particular area or competency.
05 DEVELOPING EPIC STORIES In Scrum, the Teams that complete the work assign effort estimates to every User Story Of
Is there any danger to estimating an Epic? Quite simply, the answer is yes Estimating Epics can be harmful because it creates a false sense of certainty for the Product Owner, who begins to believe that the requirements, Tasks, and effort of the Epic are known When a Team estimates an Epic, that estimation is just that—an estimation—but it seldom remains a best guess It is often used for forecasting, which, in turn, becomes the basis of a budget
When that happens, that estimate is now an inflexible projection that binds the Team to complete an unknown amount of work while respecting an established budget
When putting User Stories onto a Product Backlog (or feature list), you should not feel compelled to break everything down until the features are nearing development Further down the Product Backlog, its fine for items to be fuzzy It is also fine for items further down the Backlog to be whole projects – large, high-level items that are not so much User Stories but more like Epics!
As an item nears development, the item should be broken down further In addition, as it nears development, the item on the Backlog should be defined in sufficient detail that the Team could reasonably estimate its size and break it into Tasks Until that time, however, it is just really a placeholder A reminder for prioritization and high-level estimating That is all
For some people, particularly those used to a more traditional project approach, who are accustomed to getting detailed specifications up-front, this can potentially feel very uncomfortable It should not The logic here is simple There is little point in defining a feature (or set of features) in detail if it may never reach the top of the priority list The other aspect of this logic is that you tend to know more about your requirements, constraints, etc as time goes by Moreover, things change People come and go Sometimes the Team has changed significantly since the original requirements emerged, so opportunities can be lost if information is frozen too early Therefore, it makes business sense to defer details until they are needed.
06 PRODUCT BACKLOG The Program Product Owner develops the Program Product Backlog, which contains a
Product Backlog Each Scrum Product Backlog has certain properties that differentiate it from a simple to-do
An entry in the Scrum Product Backlog always adds value for the Customer
The entries in the Scrum Product Backlog are prioritized and ordered accordingly
The level of detail depends on the position of the entry within the Scrum Product
The Scrum Product Backlog is a living document
There are no action-items or low-level Tasks in the Scrum Product Backlog
Figure: Example of Scrum Product Backlog (also see Product Backlog), To Do List ID, Story, Estimation, Priority For instance: ID 7: As an unauthorized User I want to create an account, Estimation 3, Priority 1, etc
The Product Owner holds accountability for the Product Backlog, prioritizing backlog items based on their business value The Development Team sizes the items, estimating their complexity or effort in Story Points or hours This collaborative process ensures that the Product Backlog reflects business needs while considering the development team's capacity.
The idea that only User Stories are allowed in a Product Backlog is a common misunderstanding By contrast, Scrum is neutral on requirement techniques As stated in Scrum Guidelines:
Product Backlog items are articulated in any way that is clear and sustainable Contrary to popular belief, the Product Backlog does not contain "User Stories"; it simply contains items
Those items can be expressed as User Stories, use cases, or any other set of requirements that the group finds useful However, whatever the approach, most items should focus on delivering value to Customers
The Product Owner plays a crucial role in maximizing product value and optimizing development efforts They gather input, consider stakeholder feedback, and make informed decisions about product development priorities This includes managing the Product Backlog, prioritizing features, and ensuring that the product aligns with overall business goals and customer needs By balancing these responsibilities, the Product Owner ensures the efficient utilization of resources and the delivery of valuable products that meet stakeholder expectations.
The Product Backlog is used to:
Capture requests for modifying a product This can include adding new features, replacing old features, removing features and fixing issues
Ensure the Delivery Team is given work which maximizes the Business Benefit to the owner of the product
Typically, the Product Owner and the Scrum Team come together and write down everything that needs to be prioritized and this becomes the content of the first Sprint, which is a block of time set aside for focused work on selected items that can be accommodated within a timeframe The Scrum Product Backlog is permitted to evolve as new information surfaces about the product and its Customers, and so new work is scheduled for subsequent Sprints
The following items typically comprise a scrum backlog: features, bugs, technical work, and knowledge acquisition In the web development sphere, there is confusion as to the difference between a feature and a bug, technically a feature is "wanted", while a bug is a feature that is "unintended" or "unwanted" (but not necessarily a fault) An example of technical work would be: "run virus check on all developers' workstations" An example of knowledge acquisition could be a scrum backlog item about researching WordPress plugin libraries and making a selection
6.2 Product Backlog between Product Owner and Scrum Team A backlog, in its simplest form, is merely a list of items to be worked on Having well- established rules about how work is added, removed and ordered helps the whole Team make better decisions about how to change the product
The Product Owner prioritizes which of the Product Backlog items are most needed The Team then chooses which items can be completed in the upcoming Sprint On the Scrum Board, the Team moves items from the Product Backlog to the Sprint Backlog, which is the list of items they will now build Conceptually, it is ideal for the Team to only select what they think they can accomplish from the top of the list, but it is not unusual to see in practice that Teams are able to take lower priority items from the list along with the top ones selected
This normally happens because there is time left within the Sprint to accommodate more work Items at the top of the Backlog, the items that are going to be worked on first, should be broken down into Stories that are suitable for the Delivery Team to work on The further down the Backlog goes, the less refined the items should be As Schwaber and Beedle put it
"The lower the priority, the less detail, until you can barely make out the Backlog item."
As the Team works through the Backlog, one must always be mindful that "changes in the world can happen"; the Team can learn about new market opportunities to take advantage of, competitor threats that arise, and feedback from Customers that can change the way the product was intended to work All of these new ideas tend to trigger the Team to adapt the Backlog to incorporate new knowledge This is part of the fundamental mindset of an Agile Team The world changes, the Backlog is never finished.
07 WORKING WITH PRODUCT BACKLOG One of the most important jobs for a Product Owner is to work with the Product Backlog, and
DEEP The Product Backlog is a living document, and it is up to the Product Owner to keep the
Let us have a look at this Product Backlog diagram;
High Small User Stories, detailed and item ready for consumption in the next iteration
Medium and Large User Stories Might need to be split into smaller User Stories, or incorporate more detail
Epics, Use Cases, larger requirements specifications, ideas
Figure: Product Backlog High, Low, Priority
The top items on the Backlog list should have enough detail for the Delivery Team to start delivering Items further down the Backlog should have enough detail to allow them to be planned
While Scrum does not mandate a specific estimation technique, Extreme Programming advocates for approximating User Stories within ideal development timeframes of 1, 2, or 3 weeks Agile Teams often opt for relative unit estimation, commonly utilizing Story Points to quantify the relative effort required for each task.
Regardless of the estimation technique used, Product Owners often require items to be estimated before they are ordered We believe that there are two estimates that should be captured, the Cost Estimate and the Business Benefit Estimate The Cost Estimate represents the amount of effort it will take for the Delivery Team to complete a backlog item and only the Delivery Team should add a Cost Estimate The Product Owner should supply the Business Benefit; this is a representation of value returned to the business when the item is complete The relationship between the cost and the benefit represents the return on investment (ROI)
Many Teams do not create Business Benefit Estimates and instead have the Product Owner use their expert knowledge to calculate the benefit estimate
The Backlog is a dynamic artifact that changes over time as we have detailed in "How does it change over time"
The Backlog is an ordered list, which means that every item in the list is part of a sequence with no two items holding the same position This rule is an attempt to break the notion that every item in the Backlog is "Priority One" By applying this rule consistently, it will force Product Owners into making decisions about the importance of one Story relative to another
It is common to order the Backlog by some combination of return on investment, risk, priority and necessity—but ultimately it is up to the Product Owner to make the tradeoff decisions.
Grooming the Product Backlog The Team (or part of the Team including the Product Owner) meet regularly to "groom the
Product Backlog", in a formal or informal meeting which can lead to any of the following:
Removing User Stories that no longer appear relevant
Creating new User Stories in response to newly discovered needs
Re-assessing the relative priority of Stories
Assigning estimates to Stories which have yet to receive one
Correcting estimates in light of new information
Decomposition of User Stories which, although high priority, are too broad to fit in an upcoming iteration
Figure: Item, Size, Estimate, Insert item, Reprioritize items, Original large item, Refine items, Delete item
The intent of a "grooming" meeting is to ensure that the Backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority, and in keeping with current understanding of the project or product and its objectives
Unlike a more formal "requirements document" the Backlog is understood as a dynamic body of information For instance, not all User Stories need to have been decomposed to a detailed level at the onset of the project; nor to all User Stories need to be estimated in detail; but it is important that at any moment a "sufficient" number of stories should be ready for scheduling in the next few iterations
An Agile Project is, no less than any other, subject to "mission creep", in the form of User Stories, which do not really yield substantial value but were thought "good ideas at the time", and entered into the Backlog lest they be forgotten In the absence of explicit efforts aimed at managing this inflation, the result will be the all-too-common pathologies of schedule and budget overruns.
Prioritizing the Product Backlog The Product Backlog in Scrum is normally a prioritized features list, containing short
Typically, a Scrum Team and its Product Owner begin by writing down everything they can think of for the Backlog prioritization This kind of Product Backlog is usually more than enough for a first Sprint The Scrum Product Backlog will then grow and change as more is learned about the product and its Customers
A typical Scrum backlog comprises the following different types of items:
1 Features 2 Bugs 3 Technical work 4 Knowledge acquisition
A Scrum Team normally express features on the Product Backlog in the form of User Stories, which are short, simple descriptions of the desired functionality told from the perspective of the user (more about User Stories in Chapter 9)
Consider the following when prioritizing:
The value of the feature to the general user
The value of the feature to the specialist user
Figure: Product backlog items, Small size—Lots of details, Worked on soon, Large size—few details, Not worked on soon
(Reach, Impact, Confidence, Effort), **Value vs Complexity mapping**, and **Kano analysis** These methods help prioritize User Stories based on factors like business value, customer impact, technical complexity, effort, and risk By applying these techniques, teams can effectively order their Product Backlog, ensuring the most important features are addressed first.
Relative Prioritization Ranking: A simple listing of User Stories in order of priority is an effective method for determining the desired User Stories for each iteration or release of the product or service The purpose is to create a simple, single list with the goal of prioritizing features, rather than being distracted by multiple prioritization schemes
This simple list also provides a basis for incorporating changes and identified risks when necessary Each change or identified risk can be inserted in the list based on its priority relative to the other User Stories in the list Typically, new changes will be included at the expense of features that have been assigned a lower priority
Defining the Minimum Marketable Features (MMF) is extremely important during this process, so that the first release or iteration happens as early as possible, leading to increased ROI Normally, these User Stories would rank highest in priority
MoSCoW Prioritization scheme: The MoSCoW prioritization scheme derives its name from the first letters of the phrases "Must have", "Should have", "Could have" and "Won’t have" This prioritization method is generally more effective than simple schemes The labels are in decreasing order of priority with "Must have" User Stories being those without which the product will have no value and "Won’t have" User Stories being those that, although they would be nice to have, are not necessary to be included
Paired Comparison:In this technique, a list of all the User Stories in the Prioritized
Product Backlog is prepared Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time Each time two User Stories are compared, a decision is made regarding which of the two is more important Through this process, a prioritized list of User Stories can be generated
100-Point Method: Dean Leffingwell and Don Widrig (2003) developed the 100-Point
Method It involves giving the Customer 100 points they can use to vote for the User Stories that are most important The objective is to give more weight to the User Stories that are of higher priority when compared to the other available User Stories
Each group member allocates points to the various User Stories, giving more points to those they feel are more important On completion of the voting process, prioritization is determined by calculating the total points allocated to each User Story
Consider the following when prioritizing:
The value of the feature to the general user
The value of the feature to the specialist user
Figure 4-4: Kano Analysis Satisfied, Dissatisfied, Need Not Fulfilled, Indifference, Need Well Fulfilled Delighters/ Exciters, Satisfiers, Dissatisfiers
Interestingly, features usually move down the classification list over time; Customers will come to expect features (e.g., cameras on phones) and these features will move from being exciters and delighters to satisfiers and eventually to dissatisfiers There are other methods like Theme Screening, Theme Scoring, Relative Weighting and Financial Analysis, which will be handled in depth in the Advanced Level Product Owner course.
08 RELEASE PLANNING Release Planning Sessions are conducted to develop a Release Plan The plan defines
Release planning Many organizations have a strategy regarding release of products Some organizations
In Scrum, Release Planning Sessions aim to facilitate iterative decision-making based on available information, in contrast to the comprehensive upfront planning in waterfall projects This allows for ongoing updates to the Release Plan as new insights emerge, ensuring that it remains aligned with project progress and updated information.
Figure: Backlog, 2 weeks, 2 weeks, 2 weeks, 2 weeks, Release
Release Planning Schedule A Release Planning Schedule is one of the key outputs of the Conduct Release Planning
Length of Sprint Based on the various inputs including business requirements and Release Planning
The duration of a Sprint can be adjusted as needed by the Product Owner and Scrum Team Initially, experimentation may be necessary to determine the optimal Sprint length Over time, if project conditions improve, the Sprint length may be reduced to enhance efficiency.
A Sprint could be time-boxed for from 1 to 6 weeks However, to get maximum benefits from a Scrum project, it is recommended to keep the Sprint time-boxed to 4 weeks, unless there are projects with very stable requirements, when Sprints can extend up to 6 weeks.
09 USER STORIES 9.1 A User Story
Creating User Story User Stories adhere to a specific, predefined structure, and are thus a simplistic way of
The Prioritized Product Backlog is a dynamic list that is continuously updated because of reprioritization and new, updated, refined, and sometimes, deleted User Stories These updates to the Backlog are typically the result of changing business requirements
As the Customer representative conceives a User Story, it is written down on a note card with a name and a brief description If the developer and the Customer representative find a
User Story deficient in some way (too large, complicated, or imprecise), it is rewritten until satisfactory—often using the INVEST guidelines (see Chapter 8.5 below) Commonly, User Stories should not be considered definitive once they have been written down, since requirements tend to change throughout the development lifecycle, which agile processes handles by not carving them in stone upfront.
Format for creation of User Story A useful format for creating a User Story is the following
"As a , I want so that "
Here is an example using the format: As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.
User Story Acceptance Criteria Every User Story has associated Acceptance Criteria User Stories are subjective, so the
In the Sprint Review Meetings, the Acceptance Criteria provide the context for the Product Owner to decide if a User Story has been completed satisfactorily It is important and the responsibility of the Scrum Master to ensure that the Product Owner does not change the Acceptance Criteria of a committed User Story in the middle of a Sprint.
INVEST criteria for User Stories The INVEST system features the following characteristics
Letter Meaning Description I Independent The User Story should be self-contained, in a way that there is no inherent dependency on another User Story
N Negotiable User Stories, up until they are part of an iteration, can always be changed and rewritten
V Valuable A User Story must deliver value to the end user
E Estimable You must always be able to estimate the size of a
S Scalable (small sized) User Stories should not be so big as to become impossible to plan or Task or prioritize with some level of certainty
T Testable The User Story or its related description must provide the necessary information to make test development possible.
10 APPROVE, ESTIMATE AND COMMIT USER STORIES The User Stories, which are input to this process, have high-level estimates from the Create
Planning Poker Planning Poker, also called Estimation Poker, is an estimation technique that uses
In Planning Poker, each Team member is assigned a deck of cards Each card is numbered in a sequence and the numbers represent the complexity of the problem, in terms of time or effort, as estimated by the Team member The Product Owner chooses a User Story from the Prioritized Product Backlog and presents it to the Team The Scrum Team members assess the User Story and try to understand it better before providing their estimate for developing it
Then, each member picks a card from the deck that represents his or her estimate for the User Story If the majority or all Team members select the same card then the estimate indicated by that card will be the estimate for that User Story If there is no consensus, then the Team members discuss reasons for selecting different cards or estimates After this discussion, they pick cards again This sequence continues until all the assumptions are understood, misunderstandings are resolved, and consensus or agreement is reached
Planning Poker advocates greater interaction and enhanced communication among the participants It facilitates independent thinking by participants, thus avoiding the phenomenon of groupthink
Figure: Fibonacci Series Cards for Planning Poker
Agile Planning Poker cards can be used for the activity, or simple numbers are written on paper prior to the meeting and distributed to Scrum Team members
Sizing and estimation using Planning Poker is an abstract method that takes the focus off the actual time in hours or days and instead puts the focus on describing the relative expense and complexity of a Task as compared to other Tasks
The Scrum Team use Fibonacci-like numbers to estimate effort: 0, ẵ, 1, 2, 3, 5, 8, 13, 20,
Number estimates are based on relative sizing that the Team feels is appropriate
Zero "0" means no effort required to complete this Story (functionality might get created due to completion of some other User Story); 1 means the Story is trivial; 5 means it’s average; 20 means it’s extremely difficult or much remains unknown
If the Team provides an estimate of 3 or 5 or 8 then those User Stories are perfect for this Team
13 means the Team is asking nicely for you to break the Story down into smaller pieces if possible
20 or 40 means the Team is telling you that Story is too big and it must be broken down into multiple smaller stories
The Planning Poker process is conducted as follows:
1 The Scrum Master allows the Team to read the Story, and, if necessary, the Product Owner or Functionality Expert explains the Story
2 The Scrum Master facilitates the discussion on dependencies, and what technical stories or technical Tasks need to be accomplished to support the Story completion
The technical stories or Tasks are noted
3 For User Stories or derived technical stories, the Scrum Master asks the developers to vote using Planning Poker method, with a "one-two-three-go!"
4 The Scrum Master then challenges the highest and lowest votes to explain their position and rationale behind their selection, i.e why they believe it is more or less difficult than their peers expect
5 The Scrum Master repeats the votes until the numbers converge and the Team as whole can agree on a number or small group of numbers
6 If the Team has not agreed on a single number then the Scrum Master decides the best number based on the number of votes, or sometimes by affording more weight to the votes of Team members who are most likely be working on that particular User Story
7 The Scrum Master assigns the effort points to the Story, a.k.a the Plan Estimate
8 Repeat until there are no more Stories or the allocated time for the meeting is exhausted.
Fist of Five The Fist of Five is a simple and fast mechanism to achieve consensus in a group and drive
The number of fingers used to vote indicates the level of agreement and desire for discussion:
Fingers shown Meaning One finger: I disagree with the group's conclusion and have major concerns
Two fingers: I disagree with the group's conclusion and would like to discuss some minor issues
Three fingers: I am not sure and would like to go with the group's consensus conclusion
Four fingers: I agree with the group's conclusion and would like to discuss some minor issues
Five fingers: I wholeheartedly agree with the group's conclusion
The Fist of Five method is also useful in certain cases to find out if people understand the discussion subject or the requirement in detail
Figure: I do not understand at all; I need to go over this again; I think I get it, but am not completely comfortable; I got it; I can explain it to someone else.
Points for Cost Estimation Cost estimation can be accomplished using relative units (e.g., effort estimates) rather than
successfully, the Scrum Team should identify a baseline User Story that all Team members can relate to Once this baseline is identified, all Cost Estimates for User Stories should be done compared to that baseline These estimates remain fixed throughout a Sprint because Teams are not supposed to change during a Sprint.
Affinity Estimation Affinity Estimation is a technique used to quickly estimate a large number of User Stories
Using sticky notes or index cards and tape, the Team places User Stories on a wall or other surface, in order from small to large For this, each Team member begins with a subset of User Stories from the overall Prioritized Product Backlog to place by relative size This initial placement is done in silence Once everyone has placed their User Stories on the wall, the Team reviews all of the placements and may move User Stories around as appropriate This second part of the exercise involves discussion Finally, the Product Owner will indicate some sizing categories on the wall These categories can be small, medium, or large, or they may be numbered using Story Point values to indicate relative size The Team will then move User Stories into these categories as the final step in the process Some key benefits of this approach are that the process is very transparent, visible to everyone, and is easy to conduct.
11 CREATE AND ESTIMATE TASKS 11.1 Sprint Planning Meeting
Decomposition Decomposition is a tool whereby high-level Tasks are broken down into more detailed, low-
Prioritized Product Backlog User Stories should be sufficiently decomposed so that the Scrum Team has adequate information to create Deliverables from the Tasks itemized in the Task List.
Dependency Tree Once the Scrum Team has selected User Stories for a given Sprint, they should then
Deliverables Dependencies also highlight the relationship and interaction between Tasks, both within the Scrum Team working on a given Sprint, and within other Scrum Teams in the project
There are numerous types of dependencies: mandatory and discretionary, internal and external, or some combination thereof For example, a dependency may be both mandatory and external
Mandatory dependencies: Dependencies that are either inherent in the nature of the work, as a physical limitation, or that may be due to contractual obligations or legal requirements For example, work on the first floor cannot begin until the foundation of the building is complete Mandatory dependencies are also commonly described as hard logic
Discretionary dependencies are optional dependencies added to the workflow by the Scrum Team based on experience or industry best practices They are not mandatory requirements but are chosen to enhance efficiency or quality For example, a team may opt to complete a specific task prior to another, even though it is not a strict requirement, because it aligns with established best practices in their domain This approach allows teams to leverage their expertise and deliver optimal results.
External dependencies: External dependencies are those related to Tasks, activities, or products that are outside the scope of the work to be executed by the Scrum Team, but are needed to complete a Project Task or create a Project Deliverable External dependencies are usually outside the Scrum Team’s control
For example, if the Scrum Team is not responsible for procuring the materials required for building the walls, then those materials and Tasks related to their procurement are considered external dependencies
Internal dependencies: Internal dependencies are those dependencies between
Tasks, products, or activities that are under the control of the Scrum Team For example, installing dry-wall must be completed before painting the wall can begin
This is an example of an internal dependency because both Tasks are part of the project In this case, it is also mandatory because it is based on a physical limitation
It is not possible to paint the wall before it is dry-walled.
Output from the Sprint Planning Meeting
Task List: This comprehensive list contains all the Tasks to which the Scrum Team has committed for the current Sprint It contains descriptions of each Task along with estimates derived during the Create Tasks process The Task List must include any testing and integration efforts so that the Product Increment from the Sprint can be successfully integrated into the Deliverables from previous Sprints
Even though Tasks are often activity-based, the Scrum Team decides the level of granularity to which the Tasks are decomposed
Updated Approved, Estimated, and Committed User Stories: The User Stories are updated during this process Updates can include revisions to the original User Story estimates based on Tasks creation and complexity factors discussed during the Sprint Planning Meeting
Dependencies: Dependencies describe the relationship and interaction between different Tasks in a project They can be classified as mandatory or discretionary; or internal or external
There are numerous ways to identify, define, and present the Tasks and their dependencies Two common methods involve the use of Product Flow Diagrams and Gantt Charts.
Task Estimation in the Sprint Planning Meeting Task Estimation enables the Scrum Team to estimate the effort required to complete a Task
One of the key benefits of this technique is that it enables the Team to have a shared perspective of the User Stories and requirements, so that they can reliably estimate the effort required The information developed in the Task Estimation is included in the Estimated Task Effort List and it is used to determine the velocity for the Sprint
In this workshop, the Scrum Team may use various techniques such as decomposition, expert judgment, analogous estimation, and parametric estimation All the techniques in Chapter 10 can be used in this Workshop.
Estimation criteria The primary objective of using Estimation Criteria is to maintain relative estimation sizes and
Scrum Team capacity refers to the time dedicated solely to project development, excluding external tasks Estimation Criteria facilitate the team's effort estimation process, allowing them to identify and rectify any inefficiencies that hinder project progress.
12 CREATE SPRINT BACKLOG 12.1 Sprint Backlog
Sprint Burndown Chart The Sprint Burndown Chart is a graph that depicts the amount of work remaining in the
A related chart is a Sprint Burnup Chart Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint
Figure: Example of Sprint Burndown chart Sprint Burndown, Remaining Effort, Day Remaining, Ideal
The initial Sprint Backlog defines the start-point for the remaining effort The remaining effort for all activities is compiled on a daily basis and added to the graph In the beginning, the performance is often not as good as predicted by the ideal burndown rate, due to inaccurate estimation, or impediments that have to be removed in order to get up to full speed.
Sprint Velocity Sprint Velocity is the rate at which the Team can complete the work in a Sprint It is usually
Generally, velocity remains fairly constant during a development project, making velocity a useful metric for estimating how long it will take a Team to complete a software development project If the Product Backlog has 300 Story Points, and the Team is averaging 30 Story Points per Sprint, it can be estimated that the Team will require 10 more Sprints to complete the work If each Sprint lasts two weeks, then the project will last 20 more weeks If a Team member is moved to another project, however, or new members are added, then the velocity must be recalculated
Figure Example of Sprint Velocity Chart for Team A Story Points Completed, Sprint.
13 DEMONSTRATE AND VALIDATE SPRINT 13.1 Sprint Review Meeting
14 SHIP DELIVERABLES 14.1 What to ship
Product Releases The Product Releases should include the following
Release Content: This consists of essential information about the Deliverables for the use of the Customer Support Team
Release Notes: These should include external or market-facing shipping criteria for the product to be delivered.
Piloting Plan A Piloting Plan is an optional input that can be used to map out a pilot deployment in detail
The scope and objectives of the deployment, the target deployment user base, a deployment schedule, transition plans, required user preparation, evaluation criteria for the deployment, and other key elements related to the deployment are specified in the Pilot Plan and shared with Stakeholders.
15 RETROSPECTIVE
Retrospect Sprint The Retrospect Sprint Meeting is an important element of the ‘inspect-adapt’ Scrum
1 Things the Team needs to keep doing—best practices 2 Things the Team needs to begin doing—process improvements 3 Things the Team needs to stop doing—process problems and bottlenecks
These areas are discussed and a list of Agreed Actionable Improvements is created
15.1.1 Explorer—Shopper—Vacationer—Prisoner (ESVP)
At the onset of a Retrospect Sprint Meeting, participants anonymously express their current mindset to gauge the collective sentiment and establish a constructive atmosphere for the session.
Explorer—Wants to participate in and learn everything discussed in the retrospective
Shopper—Wants to listen to everything and choose what he takes away from the retrospective
Vacationer—Wants to relax and be a tourist in the retrospective
Prisoner—Wants to be elsewhere and is attending the retrospective because it is required
The Scrum Master then collates the responses, prepares, and shares the information with the group
Speedboat is a technique that can be used to conduct the Retrospect Sprint Meeting Team members play the role of the crew on a speedboat The boat must reach an island, which is symbolic of the project vision The attendees to record engines and anchors use sticky notes
Engines help them reach the island, while anchors hinder them from reaching the island
This exercise is Time-boxed to a few minutes Once all items are documented, the information is collated, discussed, and prioritized by way of a voting process Engines are recognized and mitigation actions are planned for the anchors, based on priority
Various metrics can be used to measure and contrast the Team's performance in the current
Sprint to their performance in previous Sprints Some examples of these metrics include:
Team velocity: Number of Story Points done in a given Sprint
Done success rate: Percentage of Story Points that have been Done versus those
Estimation effectiveness: Number or percentage of deviations between estimated and actual time spent on Tasks and User Stories
Review feedback ratings: Feedback can be solicited from Stakeholder(s) using quantitative or qualitative ratings, providing a measurement of Team performance
Team morale ratings: Results from self-assessments of Team member morale
Peer feedback: 360 degree feedback mechanisms can be used to solicit constructive criticism and insight into Team performance
Progress to release or launch: Business value provided in each release, as well as value represented by the current progress towards a release This contributes to the motivation of the Team and to the level of work satisfaction
15.1.4 The outcome of the Retrospect Sprint Meeting
Agreed Actionable: Improvements: Agreed Actionable Improvements are the primary output of the Retrospect Sprint process They are the list of actionable items that the Team has come up with to address problems and improve processes in order to enhance their performance in future Sprints
To ensure timely improvement implementation, the Scrum Team assigns specific action items with corresponding due dates These action items are meticulously defined, ensuring clarity and accountability within the team Adhering to predefined deadlines fosters efficiency and promotes progress tracking, ultimately driving successful project outcomes.
Proposed Non-Functional Items for Prioritized Product Backlog: When the initial
Prioritized Product Backlog is developed, it is based on User Stories and required functionalities Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review or Retrospect Sprint Meetings These items should be added to the Prioritized Product Backlog as they are discovered Some examples of non-functional requirements are response times, capacity limitations, and security related issues
Retrospect Sprint Log: The Retrospect Sprint Logs are records of the opinions, discussions, and actionable items raised in a Retrospect Sprint Meeting The Scrum Master could facilitate creation of this log with inputs from Scrum Core Team members The collection of all Retrospect Sprint Logs becomes the project diary and details project successes, issues, problems, and resolutions The logs are public documents available to anyone in the organization
Scrum Team Lessons Learned: The self-organizing and empowered Scrum Team is expected to learn from any mistakes made during a Sprint These lessons learned help the Teams improve their performance in future Sprints These lessons learned may also be documented in Scrum Guidance Body Recommendations to be shared with other Scrum Teams
There may be several positive lessons learned as part of a Sprint These positive lessons learned are a key part of the retrospective, and should be appropriately shared within the Team and with the Scrum Guidance Body, as the Teams work towards continuous self-improvement
Updated Scrum Guidance Body Recommendations: As a result of a Retrospect
Sprint Meeting, suggestions may be made to revise or enhance the Scrum Guidance Body Recommendations If the Guidance Body accepts these suggestions, these will be incorporated as updates to the Scrum Guidance Body documentation.