It's often difficult for new Scrum teams to understand estimating as a relative measurement rather than a specific time designation. This post, written by Doc List, helps Scrum professionals approach this complex concept with simple exercises and tools.
Once upon a time, there was a Scrum team that was new to the methodology. It was their first backlog grooming session and they needed to prioritize their newly written user stories. One of the team members remembered story points during their Scrum training.
“Should we estimate?” she asked?
“Yes, but how do we get started? I mean, how do we know what a 1 or a 2 is?”
Sizing with story points is an important Agile practice because it informs the team of the complexity of each story. Estimating is a valuable tool because it enables Product Owners and the rest of the team to have a good idea of the number of stories that can fit in the upcoming Sprint in addition to having a method in which to describe the work to stakeholders.
In order to start estimating or sizing with story points, you have to set your scale first. We’ve listed a few of our favorite ways to do so below. Before we get to specific tactics, let’s discuss two common mistakes: believing that the point is an exact number and relating a point to a unit of time.
One estimate has no value alone; it must be assessed in relation to other estimates. Take this scenario, for example.
- How tall is Jim?
- Jim is taller than Sue.
In order for the answer to make sense, the person asking the question needs to have an idea of how tall Sue is. Therefore, story points are not an exact number but a comparison. “Jim is taller than Sue” is a comparison; “Jim is 5’11”” is an exact value.
Second, estimates in story points are not a measure of time. Rather they are a measure of complexity comparing stories to one another. Instead of wondering about the relationship between story point and time, ask yourself “what is my scale?”
Getting Started: 3 Affinity Estimation Methods
One of the first things a Dev team should do is set their scale through affinity estimating. In affinity estimation, each story is grouped according to similar complexity. Each group is then assigned a value, whether a size or a number, creating a scale.
The scale is unique to the team as each team has different skillsets and is capable of achieving various things. Establish a new scale if the team has never worked or estimated together. A new scale is also needed if the team is working with a new skill set like transitioning from web to mobile development.
For each of these methods, you will need to write each user story down on an index card. All of these exercises can also be completed with or without discussion. I prefer for the facilitator (SM) to allow questions or conversations (with limits!) as it provides more opportunity for learning about the work that will eventually be completed.
T-shirt Sizing
Pro: T-shirt sizes allow beginners to focus on the range and relative complexity without associating it to a number.
- T-shirt sizing is a specific example of bucketizing. The team starts with three buckets: S, M, and L. You can create columns on the board or even have a physical bucket–just some way to categorize physically.
- Each person – in turn – takes an index card and places it in a category.
- Repeat with each person on the team until all cards are placed.
- You can expand the three categories or sizes into six if you choose to (and you probably will) adding XS, XL, and XXL.
You can do this exercise without speaking or with some discussion.
White Elephant Story Point Estimation
Posted by Don McGreal on TastyCupcakes.org, this is a great Agile twist on the white elephant gift exchange.
Pro: Opportunity for conversation and team feedback after independent thinking. It is a timed exercise so there is less of a chance to get mired in the details.
- Create six columns on the board (XS, S, M, L, XL, XXL)
- Shuffle a stack of user stories
- Each person takes a user story from the pile and reads it out loud.
- They have one minute to assign the card to a column. The team member explains why they chose that particular column.
- Next person goes.
- After a few turns, team members can choose to move a card from a column (with explanation) instead of choosing from the stack, like stealing a gift during a holiday white elephant gift exchange.
Stories that are not designated within the one-minute time are allocated to the middle column.
Source: http://tastycupcakes.org/2009/09/sizing-game/
High, Low, Lineup
The goal of this exercise is to sequence the stories from smallest (least complex) to biggest (most complex). You will need a large wall to do this exercise.
- The SM places the stories in a pile.
- The first person takes a story from the pile, reads it and places it on the wall.
- The next person takes the next story and places it to the left or right of the previous story. The left side of the spectrum is least complex, the right side is most complex.
- Everyone gets a turn placing the stories within the growing sequence until all stories have been placed.
Source: http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/
Allocating Value
Once the stories have all been grouped by similar complexity, it’s time to assign values to each group. Most people in the community use Fibonacci numbers 1, 2, 3, 5, 8, and 13 with stories dubbed as “1” being the least complex and “13” being the most complex.
Test the new scale with a few stories. Ask the team, if a story marked as “2” is twice as big as a story that is a “1.” Is it about half as complex as a story that’s a “5?”
Creating Your Cheat Sheet
After the team has done affinity estimating a few times and have set a baseline, they can move onto poker planning. However, it’s helpful for new teams to have cheat sheets. You can do this a couple of different ways. You can display stories (2 – 3 of each size) that exemplify each value within your scale so it is readily available and visible to the team. You can also create a cheat sheet to give to each team member. Feel free to use our template below.
These exercises are ways to drive conversation about the work that will be completed during the Sprint. The estimate does not mean anything. It is merely a reflection of our understanding compared to our other stories at a given point in time.
Agile Velocity’s mission is to accelerate organizational Agility through coaching and training. Based in the Silicon Hills of Austin, TX, Agile Velocity has worked with Fortune 50 enterprises and growing product companies across the United States lending a pragmatic and personal approach with each engagement. For more information, visit www.AgileVelocity.com or email [email protected].