For those of you just tuning in, this is the 12th episode of the blog series “20 Controversial Topics of Debate in Agile“. First off, let me just say that the word “estimate” is not really the right one to use which sizing a User Story. I think a better term is “sizing”, so I will use this term rather than estimating in this blog. Let’s reserve estimating for the numbers assigned to tasks that are estimated in hours.
Modified Fibonacci Scale
This is by far my favorite method of sizing User Stories, but it’s also the most difficult method to describe to others in a way that makes sense. So, what is Fibonacci? If you’re not a mathematician, you may never have heard of it. It’s a term used to describe how numbers added to the previous number in a sequence spiral out. See what I mean? It’s hard for me to describe without showing you a picture (see below).
This method of sizing stories is not meant to be precise. It’s merely an attempt to guess at the size of User Story relative to another, in what’s called “A rough order of magnitude”. If you want to know more, check out Mike Cohn’s blog about Fibonacci.
Unless this concept is introduced and taught to new Agile teams right away, the team may never mature to the point of using this type of sizing.
PROS
- Takes time completely out of the picture
- Once you wrap your head around it, it’s easy
- The most common sizing method for Scrum
- Encourages discussion and collaboration
CONS
- It’s sort of an abstract concept
- Can be difficult to explain
- And can also be difficult to understand
- People not familiar with it won’t get it
- There can be a tendency to inflate story sizes
T-Shirt Sizes
This is a much simpler method of sizing User Stories. It’s logical and makes sense to most people, so you don’t have to explain what it means. People just “get it”. For new Agile teams that resist the idea of using the modified Fibonacci sequence, this is a good alternative. It’s still a form of relative estimating. However, people may still get caught up in trying to apply some hourly estimates to the different T-shirt sizes. The thing is that hours are not the only consideration for sizing stories. You must also consider things like complexity and risk.
PROS
- Easy to understand
- Can be converted to numbers to count points
CONS
- It’s less sophisticated than Fibonacci
- There can be a tendency to assign time to the sizes
T-shirt icon made by Freepik from www.flaticon.com
Dog Breeds
Using dog breeds to size User Stories is similar in T-Shirt sizing in many respects, but it’s a little bit closer to Fibonacci, in my opinion. The problem with this is that not everyone is a dog person, and if you don’t know the approximate sizes of the breeds relative to others, you might not be able to use this approach. I’m one of the “non-dog” people, so this probably wouldn’t work for me.
PROS
- Easy to understand
- Can be converted to numbers to count points
CONS
- If you don’t know dog breeds, it won’t work as well
Ideal Day
I’ll be honest – I don’t like this sizing method. Again, it makes me think that the size is still being somehow tied to an element of time. The concept with this is that if all things were perfect, how many “ideal days” would it take to complete a User Story. I have been on teams that used this approach, and it was only “okay” compared to other sizing approaches. In other words – I don’t recommend using it.
PROS
- It’s simplistic
- More intuitive than Story Points
CONS
- Includes time as a sizing factor
- There’s no such thing as an ideal day
No Estimating / Story Count
The is the nirvana of User Story sizing: not sizing at all. This is only possible with the most mature and high-performing teams. On teams like that, the stories are written “right-sized”, where they are of similar size and the team’s output is so predictable that they just know how many items they can complete within a Sprint.
PROS
- Only applies to high-performing, mature teams
- Saves a lot of time and debate
CONS
- It takes an expert to write stories in this manner
- Forecasting may be more difficult
Final Thoughts
At the end of the day, it’s up to the team to decide what they’re comfortable with and what works best for both them and the people they report to.
So, which method do you use to size your User Stories? Are you aware of any other creative methods? If so, drop me a line and let me know!
Next up in this blog series:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can Agile co-exist with Waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?