Determining the Level of Effort for User Stories Sprint Estimation Tool

No ratings

How do you plan how long each user story takes to build? Use the Sprint Planning Tool (aka Planning Poker). While it may seem a bit silly to play a card game to determine level of effort, using this tool results in:

  • A stronger project team. This collaborative task serves to enhance team dynamics and define roles within the team.
  • Diverse perspectives. Two heads are better than one; more are better.
  • Consistency. Planning poker provides a unit of measure that you can use to easily recalculate how long all of the user stories will take if your estimate is off.

 

Cards are an important part of this tool. Members of the team make estimates by playing numbered cards face-down on the table, instead of speaking them aloud. The cards are revealed and the estimates are then discussed. By hiding the numbers and sharing them all at once, the team avoids bias – where the first number spoken aloud sets a precedent.

 

PP Cards.png

 

What do you need?

  • Each person needs a set of poker planning cards. Alternate: have participants download a mobile app. They will need a standard set of Agile Scrum cards – search in the app store for Agile Scrum Planning.
  • A moderator to facilitate the voting and decision making process and keep time.
  • Seating around a table, so everyone can see the cards.

 

Determine a baseline

The first step is to share the baseline – or in other words, the number of points for a user story of medium complexity and medium build time. In the example below, the baseline is 8 points. The baseline should be between five and 13 story points. This table can be found on the Sprint Planning tab of the Agile Implementation – The Anaplan Way app.

 

pp baseline.png

 

It is important to understand how this baseline works. The base line IS NOT a straight estimate of time, it is an estimate of complexity and effort that equates to time. The difference is subtle but important.

 

In the example above a story with Medium complexity and Medium time equals eight points, while one with Medium complexity but Low time is two points, and Medium/High is 20 points. If the group decides each point is worth two hours of development time then the Medium/Medium story should take 16 hours to develop, the Medium/Low should take four hours, and Medium/High equals 40 hours.

 

This comes into play if adjustments are needed. If, for example after the first sprint, the group discovers their estimate was wrong it can be corrected quickly. Say the stories that were Med/Med only took eight hours (half the time estimated). With this system, you can just go through and refigure the math (done automatically in the Anaplan Way app). Now the story ranked two points would change from four hours to two and the 40-hour story is reduced to 20.

 

This allows you to quickly recalculate not only the story build times but also sprints. In this example, we can now put more stories into each sprint, decrease the time estimate for the release date or add more stories to this release from the master bucket all because the stories are not taking as long as the original estimate.

 

Determine meeting time

Next, determine how many minutes to spend estimating each user story during the meeting. Take the number of minutes the team will be meeting and divide by the number of stories to determine how much time you have for each story.  For example, the team will be meeting for the rest of the day, so you have about 6½ hours of working time (taking breaks into account) and you have 75 user stories. That’s 390 minutes / 75 = ~ 5 minutes per story.

 

Voting process

 

Step

Time

1.

The user story owner gets up and reads the story to the group in such a way as all can understand it and can vote on how long they think the user story will take to create, end-to-end. The user story owner can answer questions or provide clarity.

For our example of 5 minutes per story, each story should take no more than 2 minutes. Five minutes – (1 minute for questions + 2 minutes for voting) = 2 minutes. 

2.

The voting members think about the story and have one minute to ask clarifying questions.

One minute

3.

Everyone has 30 seconds to pick the card that represents the number of points for the user story.  

Steps 3 – 6 take up to two minutes.

 

 

4.

When the 30 seconds is up, the moderator calls for the vote and everyone shows his or her card. 

5. If there is consensus, the points are recorded and the team moves on to the next user story (step 1). If there was not consensus, continue with step 6.

6.

If there was not consensus, but there are consecutive cards, the higher card is chosen for the user story points. If there was not consensus and the cards were not consecutive, then the moderator calls for one minute of discussion and a re-vote. If there is still not consensus, the moderator adds the user story to the parking lot. The user stories in the parking lot will need to be re-visited at a later time.

 

At the end of voting, you’ll have story points for each user story. In the Agile Implementation -The Anaplan Way app, assign a multiplier for the project. Begin with two or three as the multiplier: see what works best by comparing the number of hours for the first sprint using the multiplier and the total number of build hours available for the sprint. Adjust the multiplier as the project progresses and model builders get past the learning curve and up to speed.

 

If you can get through user stories and have some time left in the day, go back to see if you can get through the stories in the parking lot. If you are out of time and parking lot items remain, schedule another meeting to work through those user stories. 

Contributors
Version history
Revision #:
4 of 4
Last update:
‎04-17-2017 09:50 AM
Updated by: