Effort vs. Time

Many people are asking the same question when they are starting Scrum.

When defining a story, one can fill out an ‘effort’ and a ‘duration’. What is the difference between these?

Effort = size = Story points

I will start with the story point.  Scrum is „little bit“ different  than other classic project management techniques. 

 

When you want to develop some feature, you have to know „size“ at first.  Imagine that you want to go to a trip. You know that your trip will be 1000 miles long. This is the size. Other variable is the time. You want to pass this 1000 miles in , says, 5 days. This is a duration. Your velocity is 1000 miles per 5 day. Velocity is value how much of progress are you able to do.

 

When we are talking about story points, we are talking about the size.

 

This size can be valuated by different units. Standard methodologies are using „men days, cost, ....“.  Scrum is using number without the unit. When you are starting Scrum, it is strange. What value I have to put in column „size“? Your first evaluation will be very hard and full of questions. 

 

We are using following scenario.  We will put all the stories in front of developers. They will choose one story that will get the number Effort=1. Typically it is small story like Story 1 - „I as a user want to save file to disk“. Other stories are valuated by numbers that are relative to this selected story.

 

For example, Story 2 - „I as a user want to calculate average values per years for every customer“ is harder story than Story 1 mention above. I as a developer think that this story is 3 times harder than Story 1. Thus I will put Effort = 3 story points.

 

 

You will do this for every story that is in your product backlog. This estimation is done by developers and testers. We, at our company, are sitting together in a meeting room with the product owner and talking about stories, what he wants for functionality. Product owner will say us as much as he can. We will ask him from a technology point of view. Some stories is changed because of implementation details, some new stories can appears as new ideas.

 

Our product is typically estimated in 2-3 full days during the planning meeting (this product was developed in one year!). Maybe it seems to long to sit for  3 days, but I promise, that this it is very effective time. Benefits: all your developers and testers known what product owner wants. Product owners meet with development team. He see development guys, so closer relations can be build. I hope that this isn’t sound as marketing speech. This happened in our teams.

 

Size of stories are estimated in the Fibonacci scale. Why Fibonacci? Because it is hard to estimate if story is 20 times bigger or 23 times. Scale is 0,0.5, 1,2,3, 5, 8, 13, 20,40,100. I suggest to split stories that are 20 and more times bigger than your Story 1. Why? It seems too complex for your developers. Maybe they can be more precise for story. Product owner can be more precise in story definition.

 

Planning Poker®

During the planning meetings we are „playing“ Planning Poker®. Every developer will get cards with Fibonacci numbers.

 

Then Scrum Master will select first story. Every developers and testers will estimates they size of the story:

-          John‘s estimation = 1

-          Bill‘s estimation = 2

-          Andrea‘s estimation = 13

During the game they hides theirs estimation. When round ends, they are going to show cards. Now they see that John and Bill are close with values, but Andrea is saying that given story will be 13 times bigger. Andrea must explain why she is thinking this number, now. They will talk about these numbers and new poker round begins. This will repeat until they will agree on just one number. This is very important! One number for story. This is the number entered in the ScrumDesk story card.

 

You, as a project manager, can be surprised, what your developers think, what ways they choose for implementation. Sometimes Andrea will see that she doesn’t understand story definition well. By Planning Poker® your developers will agree on the implementation, on the story size even they don’t known technology precisely. For example, John can known SQL Server very well, Andrea don’t John can explain to Andrea about the implementation‘s simplicity. Andrea can than find out what she doesn’t known until now. Result? Knowledge and experience are balanced across a team.

 

You can meet with other estimation technique. It is an „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 what ideal day means in „real time“. For example, my ideal day is 6 hours, although my work day is 8 hours. 2 hours is for meetings, phone calls, emails. We were using ideal days one year before, but later we have found it as a harder technique. Every developer has different „ideal day“. Size in story point is better for estimation.

 

Resources

Go to  our Articles page http://www.scrumdesk.com/articles.html . You can find the Scrum quick overview and Mike Cohn’s presentations at Google there.

 

 

I suggest to read „Mike Cohn: Agile Estimating and planning“. This is one of the best book about the project estimation. 

 

Another one is Henrik Kniberg: Scrum and XP from the Trenches. This book is perfect for Scrum Starters and it can be freely downloaded from a page. Must read book