How do you estimate with Story Points and determine Velocity when you’ve not done it before?

As Captain Spock said to Lt. Saavik in Star Trek II – The Wrath of Khan – For everything, there is a first time. Taking a whack at estimation with story points the first time may seem as daunting as taking the Enterprise out of space dock the first time. Does it have to be that daunting? Scrum stresses empiricism. John Locke asserted that knowledge comes primarily from sensory experience. Put another way – we learn by doing and that the mistakes we make along the way, are just teachable moments – to be applied to future efforts. If Agile is new to you and the course you’ve chosen is Scrum as a means to apply the Agile principles, then you may very well be encountering your “First time” with story point estimation.

First, a brief primer on Story Points and Planning Poker. I’m making a blatant assumption here that you are at least aware of the existence of these concepts. Much has been written about their detail and I’ll defer to those existing sources. At its most basic level, Story Points are a representation of effort and complexity to deliver a User Story (AKA Business Requirement). A User Story may be something like “As a visitor to the website, I need to be able to login with my facebook account.” The Fibonacci Sequence is often used as the basis of Story Point values: 1,2,3,5,8,13,21,…. Other approaches are shirt sizing: S, M, L, XL, … I like numerical representations because a velocity can be calculated by simply summing up what can be accomplished in a given time period.

In conjunction with Story Points, there’s Planning Poker. In simple terms, team members each have a deck of cards, When a User Story is discussed and when it comes time to estimate, team members offer their card (which contains a number). This is their opinion as to the effort/complexity required to deliver the story under analysis. All of this goes to building and grooming the Product Backlog.
Another core concept is Velocity. How many Story Points can a team deliver in a given time period (Sprint)? This gets to the gist of this post. If your team has never estimated with Story Points and Planning Poker, it follows that a Velocity has never been calculated either. So then, how do you do this the first time?
Note – this is just this developer’s and author’s opinion. I am in no way suggesting that this is THE one right way to handle this situation. I also don’t claim to be 100% original here. There is the concept of Reference Stories which touches upon what I’m discussing here. This is simply an approach I’ve used and have found success with and accordingly, am sharing here.

Step 1: Limit the Story Points to 3, 5, 8, 13 and 21. In my experience, nothing is ever a 1 or a 2. On the other side of the spectrum, 34 and above is almost always more than just 1 story. If you are thinking shirt sizing here, then 3 is small and 21 is extra-large. I also like 5 items because under this rubric, there is a middle number and the middle corresponds to medium.

Step 2: Pick a 2 week period in your recent. Look at and group all the things you got done in that 2 week period. To the best of your ability, stack rank the items in terms of effort and complexity. From this group, isolate those items that have the feeling of being in the middle ground. Those are your 8’s. From there, you can decide whether you have 1 or levels of complexity above or below. In other words, if you just want to stick to 5, 8 and 13, you can do that. On the other hand, if from your analysis, you can discern 2 vs. 1 level of complexity in either direction, then you will want to stick with the 5 different values.

Step 3: Sum up the points. That’s your velocity over a 2 week period. I’m not suggesting your multiply by 2 or divide by two to get our 4 or 1 week velocities. What I am suggesting is a small enough time period where you can get feedback and for the first few sprints, your basis is from what came before. During your sprint reviews and retrospective, you can then determine the veracity of your initial velocity estimates. The key in all of it is to be honest and candid. If those values are not reflected in the exercise, it will be a painful process! Clearly, of the 3 steps, #2 is the most difficult. As my good friend Rich Hundhausen often says “What we do is hard.” I’m not here to suggest it’s easy. Rather, I’m simply suggesting an approach for the first Sprint and consequently, rejecting the notion that you can’t work from an imputed velocity from day 1.


UPDATE:

If you cannot isolate things that were started and completed in a 2 week period, try expanding to 3 weeks. If that does not work, then go to 4. If you still can’t isolate things, then you need to get to some time period where you can. If you need to stray beyond 4 weeks, you then need to take a look at those items and run through the process of functionally decomposing them to stories that could fit in a time period that is <= 4 weeks. If you can do that, then you may be able to apply what I discuss above. Again – I never said it would be easy!! :-)

About johnvpetersen

I've been developing software for 20 years, starting with dBase, Clipper and FoxBase + thereafter, migrating to FoxPro and Visual FoxPro and Visual Basic. Other areas of concentration include Oracle and SQL Server - versions 6-2008. From 1995 to 2001, I was a Microsoft Visual FoxPro MVP. Today, my emphasis is on ASP MVC .NET applications. I am a current Microsoft ASP .NET MVP. Publishing In 1999, I wrote the definitive whitepaper on ADO for VFP Developers. In 2002, I wrote the Absolute Beginner’s Guide to Databases for Que Publishing. I was a co-author of Visual FoxPro Enterprise Development from Prima Publishing with Rod Paddock, Ron Talmadge and Eric Ranft. I was also a co-author of Visual Basic Web Development from Prima Publishing with Rod Paddock and Richard Campbell. Education - B.S Business Administration – Mansfield University - M.B.A. – Information Systems – Saint Joseph’s University - J.D. – Rutgers University School of Law (Camden) In 2004, I graduated from the Rutgers University School of Law with a Juris Doctor Degree. I passed the Pennsylvania and New Jersey Bar exams and was in private practice for several years – concentrating transactional and general business law (contracts, copyrights, trademarks, independent contractor agreements, NDA’s, intellectual property and mergers and acquisitions.).
This entry was posted in Agile and tagged , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Comments are closed.