I just received this question from one of my co-workers and, because I get it frequently, I thought I would post both the question and my response to it. She is on a project that has been going for some time now but which was being driven through old/traditional PMI techniques. Because it was failing, as those techniques do about 85% of the time, we recently transitioned them to Scrum. She writes:
One thing that everyone wants to know is "when will we be done with the project" - and that would mean that we go through every story - spec out every task - assign points/owners to each. So I am confused about two things:
1. Where does the team find the time to do this for every post-it on the backlog wall? I am assuming the whole team needs to be involved in this exercise.
2. Points do not translate into time taken. So let's say even if we did do 1, all we would get is points. How do I convert this into "this project will be done by date xx/xx/xxxx".
Any help you can provide will be great.
My response is below:
You're right to be concerned about the size of the task in front of you. It's going to be a bit dicey and time consuming to get things set up, but it will be well worth it.
You are correct that the entire team needs to come together to create estimates in Story Points for every card (User Story or Story Card) on the Product Backlog. While it would be excruciating to break each card down to the task level before estimating, that is thankfully not necessary.
The first thing to remember is that up to 5% of your Sprint length should always be allocated to helping your SPO get better visibility/estimates on the Product Backlog. For people on a one week Sprint, like yourself, that is about 2 hours per week of estimating effort. To do the estimates efficiently, you'll want to subdivide your Product Backlog into three zones.
Zone One needs to be estimated in detail, with negotiations when estimates vary widely and thorough discussions to reach consensus. Zones Two and Three should receive quick/rough estimates where you, as the Scrum Master, may choose to either average the votes or select the high vote from the first ballot. Because Zone Two is slightly more digested than Zone Three, this will provide more accuracy in Zone Two than in Zone Three. Expect the team to protest this behavior but assure them that they will get to re-estimate each card as it moves between Zones and is broken down.
So how does all this result in a date? Once you have a rough estimate on the length of your Product Backlog, you use the team's calculated Velocity to estimate how many Sprints worth of work remain to be achieved. So, for example, suppose you go through this exercise and find that you have 612 Story Points of estimated work on your Product Backlog. If your team's Velocity is 72 Points per Sprint and Sprints are one week long, then you know that you have (612/72=8.5) Sprints worth of work to achieve, or a little over two months. Because the boundaries of the Sprints are all firmly fixed (no sliding or changing begin/end dates!) then you can translate this number into a date.
Now what if 8.5 weeks is too long? The first thing you'll want to do is to be sure that you are only pursuing mandatory work during that time. Remove any unnecessary User Stories from the calculation and re-estimate the delivery date. If it is still too long, see if you can outsource some of the work to another team. If that is not possible, and because Scrum is the only framework ever proven to scale linearly, you can ask them to give you more resources. The trick here is that you have to continue to respect the "7 +/- 2" rule on team size and may have to make multiple Scrum teams.
I hope this helps but let me know if you have further questions.
