This is based on a true story of a project I was involved in and that was also the first ever Agile projects I worked on. As I came from straight from waterfall background and didn’t have enough Agile experience, it made a lot of sense to us to map a story point with number of hours for obvious reasons. We mapped story point with ideal hours. Initially things went well. However after a few months, we started getting into difficult waters because of following problems:
We began to witness clashes among developers over estimations. As story point was mapped with number of hours, it directly mapped with the skill of a developer. For instance, a senior developer could finish a user-story in 2 hours. Another not-so-skilled developer or new-in-the-team developer could finish the same user-story in say 8 hours. That started causing planning meetings with clashes, disagreements and also spurts of indirect bullying from senior guys. As a result, not so experienced developers started spelling similar smaller estimates even though it caused them to work longer hours. As it was a distributed augmented team, we also started witnessing lack of trust within team because of those reasons.
Also customer didn’t see any significant change in team velocity even though productivity improved multi-fold. “YOU ARE NOT PRODUCTIVE GUYS…”
That put immediate pressure on the team and in order to improve so-called productivity, vicious cycle of long hours and impending burnout continued.
“Customer didn’t see any significant change in team velocity…” is an important and interesting statement. What exactly does that mean?
To understand that a bit, let’s take an example:
Let’s say in the first sprint as team was not that much experienced in the project, to complete X amount of work, team estimated 10 story points. As team mapped 1 story point with 8 ideal hours, total estimated hours meant 80 hours.
After some sprints (let’s say 8), as team had a very good hang on the project, the work which they could finish in 8 hours in first sprint, now could be finished in 4 hours only. So productivity improved but velocity didn’t. Really? Why??
Let’s look back to the work of sprint 1 at the end of sprint 8. Team now could finish that same work in 40 hours instead of in 80 hours. But as 8 hours is mapped to 1 story point, team velocity turned out to be only 5 story points instead of 10 points.
So irrespective of how much productive the team is – velocity will not change significantly and that will put continued pressure on the team. If team spends extra hours to improve that vague sense of productivity, you see the end result will be total burnout of the team.
Conclusion
That’s the one of the basic reasons why we try to map a story point with amount of work involved instead of hours. To complete a story, the amount of work remains same irrespective of the seniority or experience of team-members. That means no more team-clashes or spurts of heroism during estimation or planning meeting. At the same time, in true sense, customer will be able to see the change in velocity or productivity.
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.
What timing… I was discussing the very same topic with a friend a couple of days back. My thought process on this suggests that the velocity is for the team and not for the stakeholders or business. What they should be concerned about is the business value that the team delivers sprint after sprint. So as the team gets smarter on the domain/technology/product, they will size the stories smaller. While the team might continue to deliver a consistent velocity and not increase velocity, they will deliver more business value which is what business should be concerned about.
Thanks
The problem is – most of the times the definition of business value is vague. That’s a different topic for yet another blog altogether. However how many times prioritization truly happens based on business value? If customer cares only business value and trusts team, you’re absolutely right, it doesn’t really matter what velocity team has.
However many a times, customer says – team is not productive. And believe me, it happens to many teams. Without any facts or data, productivity is a vague term.
I wouldn’t agree that the definition of business value is vague. Looking at some serious projects that I have been part of, business value for stakeholders is what they want the teams to deliver in terms of functionality and on the other side business value for team is ensuring that they deliver what they commit.
Having said that, customer will always expect that little bit extra from the team and the team itself should keep looking for opportunities for improvement. These might not necessarily be about constantly increasing velocity. For me if a feature used to take a sprint to deliver and now the team delivers 2 such features each sprint, I am be a happy business user.
I beg to disagree with your definition of business value. Will explain my opinion in the next post. Thanks for your feedback.
I could foresee 3 glitches in this game….1) Mapping story points straight away with skill sets 2) Claiming vague business value and 3) Ignoring ‘learning curve’s impact.
While mapping story points its good to refer historical data in OPAs for a ROM. If OPA is not in place, collaborate with customer and team, assess the ROMs not from best available talent in the team perspective but from moderate talent. Then the PM can leverage better velocity by distributing sprints among team observing the throughputs/capabilities.
IMO, business values are typically assessed with be-spoken statisical tools like pay backs, NPVs, monte carlos so on… Hence key stakeholders are expected to have a near- to- realistic vision for business value. For example, by implimenting the new solution my business can save 10% overtime costs or response time be reduced from current 2 minutes to 1 minute….so on.
Its pretty natural phenomina to win savings along side the project progression as the team gets accustomed to the project relatively mutiple times than what it is initially with first sprint. So its not a good idea to compare velocity at par with productivity. Here the productivity is pretty pinnacle but the velocity (might) be low. IMO, velocity is as good as stretching from the very begining (of the project) disregarding progressive celebrating milestones.
This is how I look at this scenario. Any biased/pitfalls in my views are welcome to be digged out.
Thanks
What do mean with OPA, ROM and NPV? That will be good for my and other reader’s understanding.
OPA = Organizational Process Assets a reposiitory of past projects.Typically helps establish a start up estimate at higher level. ROM = Rough Order of Magnitude. Typically, at the very initial sprints we’re not sure about the likely completion times.We employ PERTs and wild guesses leveraging experts opinion for schedules. NPV=Net Present Value. Its used to calculate present value of investment leveraging its potential value after n years. Usually this is employed as a measure to select projects/validate ROIs.
For Velocity, I also contributed the same as other contributors did.It stretches from the begining [1st Sprint] whereas, productivity leverages on ‘learning curve’. The more we keep learning from sprint to sprint, the lesser time we take for completion. Hence I find it odd to caompare velocity with productivity. EOD, its one of the mesures to validate productivity and not by itself tantamount to productivity. I’m not sure how far my message reaches the audience.
In my view, velocity can be a measure of productivity improvement for a team but only at the start (maybe first 6-8 sprint) but in long run velocity cannot and should not be used as a metrics to measure performance rather it should be just used by the team and for the team to get some predictability to map their release plan or to give some high level cost estimates to management. In the long run, consistency in velocity is important than increase in velocity.
In case a team is showing continuous improvement in velocity over a long period it should be seen with a dash of doubt and warrant a check on whether the team is faking out velocity.
Great points Ashish. Agreed.
Thanks Ashish. This is exactly what we discussed a few days back. Thanks for making it so simple at the end 🙂
Take a look for an excellent discussion on this blog at LinkedIn “Agile Coaching” group –
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=272060875&gid=114569&commentID=163723320&trk=view_disc&fromEmail=&ut=1oD_ipBtA7KRU1
Were you using these estimates just to help the team do sprint and release planning or were you also using them to e.g. base prices on or inform business decisions?
Totally agree it really demotivates the developers. Customers are benefited with those tiny fixed time projects (tasks) that’s it while it creates lot of issues in the team and become night mare to do people management.
I wonder why you still consider this process as Agile in which developers map hours with story point, according to me it does not remain Agile/Scrum at all once you start doing it.
We tried implementing Agile once as our client had fixed budget with a deadline but in that case client was not behind each story point hours thus we managed well with high priority tasks with less features.
While in another case it did not work out well as client took advantage and start negotiating each Story point. The worst scenario ever!!!
@Kurt The estimates were for doing the sprint.
Shrikant,
Thanks, all these days I’m confused with efforts vs story points, your article with example explains all. Also agree with Ashish, after 6-8 Sprints velocity may not improve and team will perform future sprints with same velocity but this gives idea for PO how much team can deliver in each Sprint, he/she now know what to expect from the team.
Mapping Sprint 1 work at the end of Sprint 8 is just a theoretical assumption.
Yes, that assumption may mean doing same work at the end of sprint 8 would be done faster. But, in real world, we don’t do same work again. Overall, the team may get experienced with project but every sprint there would be new work with new challenges and people may also change. So, velocity may increase but not significant enough for customer to say team is more productive or not.