It is difficult to estimate the effort involved in a task or user story, particularly within a sprint or time box. This workshop will help your team quickly estimate user stories.
90 minutes for workshop (full team), 2 hours prep time (Agile Project Manager)
The user story cards from the previous exercise, and a Planning Poker tool.
Everyone understands basic Planning Poker and how to come to a consensus for a high level estimate.
To make effective estimates on how quickly your team can complete tasks, think abstractly in terms of size instead of actual units of time. For example, consider the Empire State Building. It’s roughly 100 stories tall. Let’s say you work in an office building that is 10 stories. It is daunting to compare how much work is required to build the Empire State Building versus a 10-story office building. If we look at this abstractly, then the Empire State Building is ten times more difficult to build than a 10-story building. Trying to determine actual time would take far too much planning and may simply be impossible.
Relative estimating frees your team to focus on problem solving and less on the actual duration. Duration is important but your team should spend more time considering work items in relation to each other, especially if a story is complex or has unknowns. Duration can be determined as more of an afterthought.
To practice relative estimating, look at the stories in your backlog. Find a simple story and compare it to a more difficult one. Is it twice as hard? Three times? Ten times?!? You’ve done it and have performed a relative estimate.
There are many Agile estimating techniques that don’t require putting an actual hours estimate on a story. A simple method is to compare one backlog item to another. You can separate them into Small, Medium and Large stories or backlog items. The team can use this technique to evaluate a large backlog in a short period of time and expand estimates to mimic T-shirt sizes: XS, S, M, L, XL, 2X, 3X, etc. This estimating style is comparatively easy but does not quantify the work to be completed. Assigning a relative number to your estimates will be useful for computing velocity (how much work a particular team can accomplish in a sprint).
Some teams have very complex backlog items. Complex does not always mean big. To visualize this, consider the attempt to put a collar on a horse, dog, cat and canary. The horse and dog are the bigger animals, but the task of putting a collar on them is fairly simple. Putting a collar on a cat becomes more complex. Putting a collar on a canary is darn near impossible even though the animal is the smallest. Perspective is key in this estimating technique.
Planning Poker is a very popular method for estimating work items. Start your sprint planning session (or workshop, in this case) with a deck of Planning Poker cards, download a Planning Poker app, or use your fingers. Planning Poker is based on the Fibonacci Sequence or golden spiral — 1,2,3,5,8,13, etc. — where we take the sum of the two values to the left, to get the new value (0+1=1, 1+1=2, 1+2=3, 2+3=5). Many people appreciate this technique because it mimics nature — Planning in Nature.
Planning Poker takes time to master. Eventually, you may find that using this method during planning sessions will be similar to a team building exercise. The team will become familiar with others’ voting tendencies. They may even tease each other and have fun with the activity. Ultimately, the team will be able to estimate quickly and effectively.
Planning Poker is quantifiable. The planning estimates can be used to determine velocity for a sprint, for instance. Velocity is the total estimation points (i.e., story points) completed in a sprint. You’ll read about story points next. They are used to express the level of effort required to complete a task.
You can average the velocity over several sprints to get an accurate glimpse of your team’s capacity. If your team is averaging 40 points per sprint then the next sprint should be around 40 points too, not much higher or lower. Choose the estimating style that works best for your team. Feel free to try various methods or come up with one yourself. For this particular workshop, we’ll be using Planning Poker.
Before the workshop begins, decide if the team will use the Fibonacci sequence or T-shirt sizes for Planning Poker. Choose a Planning Poker tool and work with the user stories that were created in the previous workshop.
This is the same group that participated in the User Story workshop so the same group may to continue their previous roles as Product Owner, Agile Project Manager, End User, and Developers. The Agile Project Manager will continue to coach the team and ensure the workshop is on track.
- Review estimating: 15 min
- Introduce Planning Poker: 10 min
- Introduce the user story: 1 min, repeat
- Discuss the work: 1 min, repeat
- Reveal estimates: 1 min, repeat
- Discuss estimates: 1 min, repeat
- Estimate again: 1 min, repeat
- Agree and continue: 1 min, repeat
As time allows, you will repeat these steps until you have enough stories estimated that would fulfill your sprint. The Agile Project Manager should encourage changes to the stories and new stories to be written at any time during the workshop. As estimating conversations occur, the team may realize that assumptions were made that aren’t represented in a user story. The goal is to practice having conversations around estimating and to come to an agreement on how much effort a story would take.
The Agile Project Manager will review estimating ideas, including the Keys to Estimation:
- “A story is a promise to have a conversation” — it does not specify all details that are needed to implement the story.
- An estimation is not a promise to complete the work in a certain amount of time.
- Team members should take no more than two minutes to estimate a story.
- A story that takes more than one sprint is too long and must be broken up into smaller stories — you won’t know this until the estimation phase.
- Do estimation in a short meeting (90 min) with engineers and story authors in the same room.
- Avoid rating your abstract story units to calendar time until you can measure from the velocity of a burndown chart for at least three sprints.
Introduce Planning Poker
Planning Poker is a tool that we’ll use to do consensus based estimates. We’re using either the Fibonacci sequence or T-shirt sizes as the unit of measure.
Introduce the user story
The Product Owner (or another team member) introduces the first story to be estimated and describes the work item to be estimated covering the presumed duration, complexity, and any unknowns that may exist.
Discuss the work
The entire team participates in a discussion on how to get the work done. They will talk about what they will need to do to get the work done and ask questions to ensure they understand the user story fully. Once the discussion is over and all the questions have been asked, then it’s time to focus on estimating again.
Each team member will select the relative number that best represents the size of the work in their opinion. The entire team reveals their numbers simultaneously so that opinions are not swayed by early revealers. If everyone chooses the same number then that will be the estimate.
If a broad range of numbers is revealed then you ask the outliers to explain their answer. The discussion continues until everyone has asked their questions.
Again, the entire team reveals their numbers simultaneously so that opinions are not swayed by early revealers. In most cases the numbers disclosed get closer to each other.
Agree and continue
The estimated exercise will conclude once your team reaches a consensus. Continue this process until there are enough work items to start working on during a sprint.
- Team members may have difficulty estimating their time for tasks.
- Stories may require more conversation than others. Do your best to stick to the timebox and remember the keys to estimation above.
- There may be disagreement on estimates and Agile Project Manager should respect this. The development team has authority on determining the final estimate. A Product Owner cannot determine the length of a task but can participate the overall estimating. Ideally, a disagreement will result in a combined, creative compromise.
- The team will need to restart the process over several times but be persistent, it’s worth it.
- Can you estimate a story quickly as a group?
- Can you explain why you’ve estimated it that way?
- Congratulations, you’ve completed your second Agile workshop!