SCRUM Estimation
Download as PPTX, PDF2 likes2,705 views
This document discusses key concepts in agile planning including story points, velocity, and release planning using velocity. It defines story points as relative sizes used to estimate user stories, and explains how they remain constant over time unlike ideal days estimates. Velocity is defined as the average story points a team can complete per sprint. The document outlines how to establish story points and use them along with velocity for release planning and tracking progress with a burn down chart.
SCRUM Estimation
- 1. * Relative Sizing What is a Story Point? Points vs Days? Why Story Points? What is Velocity? How to establish Story Points? Story Point Assignment Release Planning with Velocity
- 2. * *To express the overall size of an object by comparison to the size of a another known object. *Example: An object of size 6 is three times the ‘size’ of an object size 2, but we have no gauge what an object of size 2 is in the absolute sense. 2 2 6
- 3. * *A relative size used to represent the estimate for a user story in the product backlog 2 3 5 8 13 20
- 4. *A story point does not change over time depending on team performance *A story point is relative * Example: A user story of 8 Story Points has been estimated by the sprint team. * Since the estimation was given, the sprint team learned a lot and is now performing at a very high level * The user story remains at an estimation of 8 *Ideal days change over time based on team performance *Ideal days are absolute but often used relatively * Example: A user story of 14 days has been estimated by the development team. * Since the estimation was given, the sprint team learned a lot and is now performing at a very high level * The user story estimate of 14 days is now inaccurate *
- 5. * *A Story Point doesn’t change over time *Simplifies estimation by using the Fibonacci sequence (0,1,2,3,5,8,13…) allowing the Sprint Team to focus on complexity *Story Points take into consideration differences in team experience levels *Commitment is removed from the estimation process and done during Sprint Planning when the team is ready to commit *Collaboration of the entire Sprint Team is required
- 6. * *The average number of Story Points a Sprint Team can complete within an iteration 0 2 4 6 8 10 12 14 16 18 20 Sprint 1 Sprint 2 Sprint 3 Sprint 4
- 7. * * Story assignment must take into consideration: * Knowns and unknowns * Complexity * Overall effort * Risk * Story assignment does not take into consideration: * Which team members will be doing the work * Time needed to complete the work * All Sprint Team members participate in the sizing decision * Create a 2 baseline stories, these are stories that have been completed previously and can be given a story point * Pick an example of the smallest story the team would work on, assign it the Story Point = 1 * Pick an average story the team would work on, not too big, not too small which can represent a middle point * Decide what your Story Point scale is going to be within the Fibonacci sequence (0,1,2,3,5,8,13,20…)
- 8. * *Relative sizing using the baseline stories through planning poker is a common approach to Story Point assignment *Planning Poker * Scrum Master facilitates a Story Pointing session * Product Owner reads the story to be sized and answers any preliminary questions the sprint team may have about the story * Baseline stories are reiterated so sprint team members can relatively size the new story * Each team member chooses their point (often in the form of a card laid face down) * Scrum Master calls for team members to expose their points simultaneously * Discussion takes place for high and low estimates * The process is repeated until a group consensus can be reached
- 9. * *A product backlog can be broken into sprints to plan a release by using the sprint teams velocity *A release can be planned by date or by feature set *The product backlog is always in priority order based on what the intention of the release is
- 10. * *A sprint team with a velocity of 25 could have a backlog like this *If an iteration is 2 weeks, by date we know which stories will make the release in 6 weeks *If an iteration is 2 weeks, by feature set, we can determine how many sprints are required to complete the stories within the feature set Most of these stories are too far out and too large to consider into the current release without further breakdown
- 11. * *A release burndown chart can be kept to measure the current release of a sprint team *Using the planned Story Points and actual velocity 75 45 23 0 10 20 30 40 50 60 70 80 90 Sprint 0 Sprint 1 - 30V Sprint 2 - 22V Sprint 3 - 24V PlannedStory Points Release 1 - Velocity Average 25
- 12. * *A release burndown chart can be kept to measure the current release of a sprint team *Using the planned Story Points and actual velocity 75 45 23 0 10 20 30 40 50 60 70 80 90 Sprint 0 Sprint 1 - 30V Sprint 2 - 22V Sprint 3 - 24V PlannedStory Points Release 1 - Velocity Average 25
- 13. * For more Agile information please visit our website www.agiletestingframework.com *
Editor's Notes
- #3: Notes The concept of relative sizing can be difficult at first By comparing the new story with a known story of size, the size of the new story can be estimated by comparison
- #4: Notes The concept of relative sizing can be difficult at first Assigning a size to a story must take into consideration knowns, unknowns, complexity, overall effort and risk The Fibonacci sequence is used to account for inherent uncertainty as the stories get larger, the larger the story, the more uncertainty, the less accurate the estimate The Fibonacci sequence also limits the number of choices causing the sprint team to collaborate and agree within the chosen scale
- #5: Notes Story points remain accurate over time unlike idea days The use of story points with the Fibonacci sequence limits the choices and is therefore faster leaving the team to focus on the story details As a sprint team matures and becomes more efficient, more stories can be taken into an iteration for completion, but the story point estimation of a story has no reason to change and is accurate Ideal days often given relatively but used absolutely. 3 ideal days can mean many things to many people. 3 days on a calendar for 1 person is different than 3 days on a calendar for 2 people or 3 days on a calendar for a senior person vs a junior person. Ideal days often insinuate commitment, story points do not as they are unit-less
- #6: Notes Story points are more accurate over time as they do not change. Using the fibonacci sequence allows the sprint team to have known choices of estimation assignment which speeds up estimation agreement, promotes less variation and more accuracy when sizing stories against other known stories Release planning becomes simple as story points become consistently accurate per sprint team Points are unit-less with no commitment associated with them at time of estimation leaving the commitment where it belongs at Sprint Planning The sprint team as a collective group discuss each story and discuss the story point size giving the group an understanding of all efforts required for a story
- #7: Notes At the end of each sprint iteration, the number of completedaccepted user stories contribute to the overall sprint team velocity. As sprint teams change, become more experienced, lose members, gain members, the velocity will be adjusted. It is self correcting. The velocity is used to determine the average number of story points a team can complete within a normal iteration.
- #8: Notes Assigning a size to a story must take into consideration knowns, unknowns, complexity, overall effort and risk from the perspective of different team members (technically, testability, data volume, environmental factors, proven vs unproven details etc) All team members participate in deciding what size assignment a story will get There is no time associated with the size of a story or a story point, story points are unit-less There is no consideration as to whom may do the work, because we do not know, and although a senior person may complete a story faster, remember, there is no time associated with a story point, therefore it has no bearing during story point assignment
- #9: Notes A sprint team’s baseline stories are reiterated at the start of a story pointing session to re-align the team members The Scrum Master will facilitate the session to gain group consensus The Product Owner reads and answers questions regarding the story being pointed to help the sprint team provide their estimate The Scrum Master must facilitate the session to avoid the sprint team from going ‘too deep’ into details during this session, the sprint team needs enough information to provide the story point based on what is known today, implementation details are not required Exposing the story point simultaneously is important, it allows each team member to provide their estimate without influence of others The team members should provide their first estimate quickly so that points that differ drastically can be discussed to shed light on a team members concerns houghts The Scrum Master will have the team repeat the process and remind them often of their baseline stories to encourage relative sizing techniques Only sprint team members get to decide a Story Point for a story as they are the people who will be doing the work
- #10: Notes At the end of each sprint iteration, the number of completedaccepted user stories contribute to the overall sprint team velocity. As sprint teams change, become more experienced, lose members, gain members, the velocity will be adjusted. The velocity is used to determine the average number of story points a team can complete within a normal iteration.
- #11: Notes A Product Owner can use a sprint team’s average velocity to release plan by date or by feature set The product backlog is ordered in priority If planning by feature set, the feature set stories will be at the top of the product backlog as they will be priority If planning by date, stories from many different feature sets will be at the top in order of their priority The product backlog is broken into sprints by using the sprint teams average velocity If planning by date, knowing the iteration cycle of the sprint team, a Product Owner can clearly see what will be delivered by a given date If planning by feature set, knowing the iteration cycle of the sprint team, a Product Owner can clearly see how many sprints are required to delivery the stories required to fulfill the feature set and determine the release date Release planning is an ongoing cycle, at the end of every sprint, the team will recalculate their velocity and the Release plan can be adjusted
- #12: Notes At the end of every sprint iteration, the total number of completed story points is added to create the velocity of that sprint The average velocity for the sprint team is readjusted Using the actual story points completed, we can reduce the planned release story points and clearly see if the release is on track Stories get added and removed from releases, this can also be reflected in the release burndown chart with adjustments to the overall planned story points Clearly gauging where a release is at the end of every iteration allows early intervention when the release gets out of line and set expectations of stakeholders earlier in the process Examples of early intervention can be: Removing some stories from the release if the release is behind schedule Re planning the date of the release to release later or earlier Adding additional stories if a release is ahead Giving some stories to another team
- #13: Notes At the end of every sprint iteration, the total number of completed story points is added to create the velocity of that sprint The average velocity for the sprint team is readjusted Using the actual story points completed, we can reduce the planned release story points and clearly see if the release is on track Stories get added and removed from releases, this can also be reflected in the release burndown chart with adjustments to the overall planned story points Clearly gauging where a release is at the end of every iteration allows early intervention when the release gets out of line and set expectations of stakeholders earlier in the process Examples of early intervention can be: Removing some stories from the release if the release is behind schedule Re planning the date of the release to release later or earlier Adding additional stories if a release is ahead Giving some stories to another team