Deleted: 
As long as a customer trusts the team, whatever way you size or estimate or don’t estimate, doesn’t really matter.
But that doesn’t happen very often. Whenever a customer questions about team throughput for whatever reasons, it becomes challenging to answer it using hour-based estimation as the number of hours (capacity of a team) remains constant.
Now if we move towards story point sizing (relative sizing) technique, it’s important not to map with time.
Here is why:
Perception of Lower Throughput
Let’s say, in Sprint 1 team decided to map 1 story point with 1 day. At that time, the team estimated 5 story points for story-A which they translated to 5 days. By the time the team moves to Sprint 10, they get experienced both from technology and domain understanding standpoint.
Now stories similar to story-A may take 3 days due to their improved experience and understanding, which translates to 3 story points.
So you see, even though throughput improved, the number of story points decreased. Instead of 5 story points, the story gets 3 story points. Though the team performed better compared to Sprint 1, that doesn’t get translated into better velocity.
Keep in mind, velocity improvement is not linear. Also it doesn’t improve beyond a point and the curve flattens. So project management should have appropriate expectation set with the customer.
Velocity Remains Constant if One Maps Story Points to Hours
As and when a team maps a story point with time, its velocity becomes almost constant just because the time (capacity of the team in working hours) remains constant.
The team management may complain that team throughput is not changing. Throughput may have already changed but it will never show up.
Instead of completing 10 similar sized stories, team may be finishing 14 already but that will never reflect as number of days required to accomplish them remain constant from sprint to sprint.
So never map a story point to time unit as that will create more problems than it solves.
So What’s the Alternative?
You may want to begin with a collaborative guess as mentioned in the other post of this blog series.
More on Story Points and Agile Estimation
This post is a part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series.
Yes Sheikant,but what would be the best way to show progress to management who looks only for velocity and throughput at the end .
Teams somehow need to estimate properly in story points or some times end up giving more story points just to meet the velocity…not good for an agile team though…
Hi Sreenivas. I am not asking to stop using story points. Use them but don’t map them with hours. The average number of story points completed in last 3 sprints becomes the velocity. Try taking a look at alternative here – http://www.agilebuddha.com/agile/how-to-forecast-the-number-of-story-points-in-a-sprint/
First of all one should not try to map story points and hours. It’s really not required. But sometimes it’s not easy to convince people.
Coming to your point about velocity, if team really wants to map hours and story points, they should change the definition of 1 story point after few sprints. So instead of 8, it can be 6. This should solve velocity related issue. But as I said in the begining it’s really not required.
More you try to solve the issue with work arounds, more you get into other issues. My suggestion based on experience so far is to begin with clean slate and it works. http://www.agilebuddha.com/agile/how-to-forecast-the-number-of-story-points-in-a-sprint/
Hi Shrikant,
Posting this as an anonymous as I don’t want to disclose my identity. I will be following the responses though.
Note: Keeping my views on whether SPs to map Hours reserve here, I just want to discuss a particular scenario in this blog (considering that we go by the method of 1 SP = 1 day)
On this paragraph, “Now stories similar to story-A may take 3 days due to their improved experience and understanding, which translates to 3 story points.
So you see, even though throughput improved, the number of story points decreased”
Not too sure whether no of Story points really decreases. If a story now take 3 SPs = 3 days, there are two more spared days, and wouldn’t team be using those two days for another 2 pointer story? Which ultimately keeps the throughput – in terms of velocity – constant. However, it will also show an improved lead & cycle time of a particular type of story over the period of time (empirically of course).
I may have understood it wrong though. Please correct me if that’s the case.
Exactly the same thought I had and you phrased it well. I agree with you that Team’s Velocity will ultimately increase even if you have mapped SP into hours. I have experience in both practices and I have seen team members taking advantage of not mapping to hours. So tomorrow’s completion date/ demo date keeps postponing but mapping to hours really controls this. Although we should not give this answer in interview as many people go by book and not experience.
I am using SP as well as PDs for large programs for more than 2 years now. I do not quite agree with below points
1) Velocity is constant for life of project
2) Mapping of SP s to PD is bad
3) There is no need to map SP to PD
If you have owned or managed large global programs where need to report the financials, above mapping mandatory.
Regarding the this mapping, I believe, I am using a practical approach successfully since last 2.5 years where calculations match for scope and capacity. Successfully delivered few releases.
It’s good it’s working for you. Never said “Velocity is constant for life of project”.