When defining a story, one can fill out an ‘effort’ and a ‘duration’. What is the difference between them?
What is the story point?
Let’s start with the story point. Scrum is „a little bit“ different than other classic project management techniques.
When you want to develop some feature, you have to know the „size“ at first. Imagine you want to go on a trip. You know your trip will be 1000 miles long. This is the size. Another variable is time. You want to pass this 1000 miles in 5 days. This is a duration. It is possible to calculate planned velocity as 1000 miles per 5 days. Velocity, therefore, defines how much progress are you able to accomplish.
When we are talking about story points, we are talking about the size (complexity). Effort = complexity = Story points.
This size is evaluated in different units. Standard methodologies use „man-days, cost, etc.“. Scrum prefers numbers without the unit. Your first evaluation will be very hard and full of questions.
The best approach to start with relative estimation is to try some examples on real-life objects. Try to compare a phone to a laptop and LCD. Use the following scenario:
- Put all the stories (objects) in front of developers.
- Let them choose one story (object) that will get the number Effort=1. Typically it is a small story like „I as a user want to save a file to disk“.
- Then compare all remaining stories relatively to a referenced story and other, already estimated stories.
For example, Story 2 – „I as a user want to calculate average values per year for every customer“ is a more complex story than Story 1 mentioned above. As a developer, I think that this story is 3 times harder than Story 1. Therefore I will set Effort = 3 story points.
You will do this for every story in your product backlog. This estimation is done by developers and testers. The team sits together in a meeting room with the product owner and talks about stories, what he wants and needs. The product owner will say us as much as he can. We will ask him from a technology point of view. Some stories are changed during the discussion, some new stories can appear as well.
The product is typically estimated in 1-3 full days during the planning meeting. All your developers and testers know what the product owner wants. The product owner meets with the development team. He sees developers hence closer relations can be built.
The size of stories is estimated in the Fibonacci scale. Scale is 0,0.5, 1,2,3, 5, 8, 13, 20,40,100.
If the story is bigger than the agreed limit (8, 13, or more) then it should be split into smaller stories. It is too complex to be developed.
If the story is smaller, developers can be more precise in their estimation. The product owner can be more precise in story definition.
Planning Poker®
During the planning meetings we “play” Planning Poker®. Every developer will get a deck of planning poker cards with Fibonacci numbers.
Scrum Master will choose the first story. Every developer and tester will estimate the size of the story:
- John‘s estimation = 1
- Bill‘s estimation = 2
- Andrea‘s estimation = 13
During the game team members hide their cards. When the round ends up, the team shows cards.
Now they might see that John and Bill are close with values, but Andrea says that the given story will be 13 times bigger. Andrea should explain why she thinks is bigger.
They will discuss the reason for the estimated number and later a new poker round will begin. These steps should be repeated until the team agrees on just one number because we look for the team’s commitment. This is the number entered in the ScrumDesk story card then.
Ideal day
Another estimation technique is based on „ideal day“. When you are using this evaluation unit, your developers must think about the day when they are not disturbed by emails, meetings, they can work for 100%. Your team must agree on what an ideal day means in „real-time“. For example, my ideal day is 6 hours, although my workday is 8 hours. I spend 2 hours is for meetings, phone calls, emails.
We were using ideal days beginning the agile transition, but later we have found it as a complex way for estimation. Every developer has a different „ideal day“. Size in story point is better for estimation as it is smaller and enough for accurate estimation.
Mike Cohn about Agile Estimation
Resources
- Read „Mike Cohn: Agile Estimating and planning“. This is one of the best books about project estimation.
- Another one is Henrik Kniberg: Scrum and XP from the Trenches. This book is perfect for Scrum beginners and it can be freely downloaded from a page.
Additional articles about Agile Estimation
How ScrumDesk supports story points?
