You don’t need story-points either

Or an estimation-less approach to software development

I’ve had too many conversations (and overheard a few) about re-estimating stories or “re-baselining” the effort required for software projects. The latest one was about when it might be a good idea to do this re-estimation, and how, and what Mike Cohn says about it, and so on. The logic appears to be that as you gain more knowledge about the software being built, you can create better estimates and thereby have better predictability. This post talks about estimates, how they are just another form of muda (waste) and what might be a better way.

First things first

Lets start with fundamentals again. In order to stay profitable and prosperous, a software products company must be competitive. If you do enough root-cause analysis, the only thing that can ultimately ensure this is raw speed. Hence, the only metric that matters is cycle-time and organizations must always try to reduce it.

OK, so now, the issue simplifies itself – all we have to do is look for constraints, remove them, and repeat – all the while measuring cycle-time (and thereby throughput). Simple enough! And in the first few passes of doing so, I first realized that if you must estimate things, use story points. Then I realized that estimation in general is a form of muda – and converting from story-points to real-hours at the start of each iteration is a really stupid waste of time.

Even less muda

Now, having said all that, we can move on to the point of this post. I’ve come to realize there is a better way. One which achieves the goal of faster throughput, with less process and less waste. Eliminate estimation altogether. You don’t even need story points anymore. Here’s how it works –

Take a list of requirements. Ensure they always stay current – you know, by talking with the stakeholders and users and all the other involved parties. Ensure it is always in prioritized order – according to business value. Again, not hard to do – you just need to ensure that the stakeholders are as involved with the product development as the rest of the team is.

Next, pick a duration – say a couple of weeks. If in your business, two weeks is too short (you’re either a monopoly or you’re on your way out) then pick what makes sense. Pick up the first requirement and break it down into stories. Here’s the trick – each story should not be more than 1-3 days of work to implement. In other words, each story, on average, should be about 2 days of development time. Simple enough to do, if the developers on your team are as involved in the process of delivering value to your customers as the business is. Pick the next requirement and do the same thing, keep going until your two weeks seems full. Do a couple more if you like. Ensure that this list stays prioritized.

Then, start developing. There is no need for estimation. Sure, some stories will not really be 2 days worth – break them down when you realize it. Sure, you need good business-analysts and willing developers. You’ve hired the best, right? Next, as business functionality gets implemented to the point where releasing it makes sense, release it! Then, repeat.

What (re) estimation?

In this scenario, there really is no reason to do formal-estimation at all. Sure, super-high-level sizing is probably still needed to get the project off the ground, but beyond that, there is no need to do anything other than deliver quality software, gather real-user feedback, and repeat.

Now come the questions of how to say how much work is done, or when a certain feature will be delivered. The dreaded “how much more work is left” questions. The answer in this new world is simply = 2 days * number of stories in question. (Remember the average story size?) Many people like to track things, but measuring actuals is also muda.

The important thing is of course to not look too far ahead. In today’s business environment, the world changes at the speed of the Internet, so luckily this works to our advantage. Whenever something changes, you just re-prioritize the list of stories. This process is not only much leaner, it is also much simpler.

Let’s come back to the issue of re-estimation. People cite the fact that during the start of a project, there isn’t enough knowledge to truly estimate the high-level requirements. Then, as the project proceeds and they learn more, they seem to want to re-estimate things. I ask, why bother?

The key here is to recognize that “accurate” estimates don’t deliver any business value. It is only important that complex requirements are broken down into incremental stories and they are implemented and released quickly.

The real benefits

The fact that this saves time and effort is actually just a good side-effect. The real value comes from being able to truly stay in control of the development process. Tiny stories allow you to change them when required, pull them from the backlog when needed, or to add new ones whenever business demands it. It also lets you move faster because it’s easier to write code in small incremental chunks, testing is easier, and pushing small releases out to users is easier.

And finally, by imposing the discipline that each story be small, it ensures that people think about the requirement deeply enough before coding begins. It also forces the team to break down requirements into incremental pieces and totally avoids never-ending stories that always have a little bit left to complete.

So there

This allows the whole process to be streamlined. It allows the team to focus on just what the users cares about (working software at their fingertips), and not on all the meaningless artifacts mandated by many methodology books (and indeed unenlightened management). Also, in this manner we handle the issue of estimation and re-estimation. In a zen-line fashion, we do it by not doing it.

Why I don’t use real hours for sprint planning

OK, so several of my friends and colleagues pointed me to Mike Cohn’s recent blog post about why he doesn’t use story points for sprint planning. I left a couple of comments on his blog, but I couldn’t wait until he moderates them… so I thought I’d post my thoughts here.

In my opinion, using either story-points or real-hours for sprint planning makes one assumption. The assumption is that it is somehow very important to get a sprint “just right”. In other words, it is important for a team to estimate a sprint’s worth of work well enough so as to make it fit perfectly within a sprint.

I believe that it’s not important at all. Here’s why.

First of all, the length of a sprint is picked by the team in a mostly arbitrary manner. Some pick 30 days, some pick 1 week. For the most part, it could be any number in between there. So if the duration is not that critical, then why should fitting work into it be? In any case, when a team happens to under-estimate, the undone work gets pushed into a future sprint. And when a team over-estimates, the stakeholders gleefully add more work to the sprint. So… what was the point of all the real-hours-based estimation?

Next, lets talk about predictability. Take an example of a basket-ball team. They can make a general statement about their long-term average, but can they predict what they’ll score in the next game? No… but even more critical, is it even important to try to make this prediction? The answer is not really, it is only important that they do their darned best. A software team can certainly spend time breaking stories down into tasks and then even more time estimating each in real hours, and then bargaining with the stakeholders to make sure whatever they pick all fits in… but it’s just more important that they work on the highest priority cards, with as less distraction and road-blocks as possible.

Whether they fit it all in, into that one sprint or not, is a mere detail.

Now, it’s not to say that having dates is not important. It is, but you can’t be scope-bound AND time-bound. Pick one. My default choice is time-bound with variable-scope. In other words, I like to set a release-date, and then ensure that the team is burning down the highest priority items at all times, as that date approaches. When the date is nigh, release! We’re all writing production-ready software, aren’t we? Then, repeat.

This approach then makes it possible to simply drive the whole project off the product-backlog… without strict sprint-backlogs. It allows velocity to be measured in story-points (from the product-backlog) and prediction is a matter of total-story-points divided by velocity-in-story-points. Simple. If anyone asks what will be done this sprint, the answer is the highest priority stories on the backlog, as many as the team can, here’s our best guess (average-velocity-in-story-points). This approach is actually faster than sitting and re-estimating individual stories in real-hours, because well, the team doesn’t have that distraction anymore.

In fact, from my experience, when the team gets comfortable doing this, they even ask… OK, so if the length of the sprint was set fairly arbitrarily, and as long as we work on the most important stuff at all times, then why are we bothering with the concept of sprints at all? These teams go beyond what I described above and eliminate the waste of iterations. Fun, eh?

If I talk about this stuff to people, sooner or later, someone brings up the happy concept of rhythm – how it is important for the team to have a pulse, a beat to which they work – sprint-planning, development, sprint-close, retrospective, repeat. It gives them satisfaction. It probably does, but I think we can do better. I prefer my teams to not just close an iteration based on some rhythm, but even push the software into production each time. Let the rhythm be set not by an arbitrarily picked number, but through customers getting their hands on the next release of the software. They still do the retrospectives regularly, and have team outings all the time. But the rhythm of the team is set through actual releases. When teams get better and better at this, and realize the critical importance of cycle-time, they do all they can to reduce it.

Anyway, I can talk about this stuff for a long time. Back to sprint-planning. My take is – do it like agile architecture/design. Think of it as evolutionary. We’ve eliminated the big-up-front-design, it is time to eliminate the big-up-front-sprint-plan. Prioritize the back-log constantly, always ensure that the team is working on the highest priority item. Ensure there are as less distractions and road-blocks as possible. And release quickly, as early and as often as possible – make a rhythm out of it.

And if the stake-holder asks when a particular story will be done, see where it stands in the prioritized backlog. The answer to the question is, of course, after all the ones above it are completed. Ask also if they would like to re-prioritize. That’s all there is to it!

If estimation is harmful… then, what’s not?

Or leaner Agile – part II
(Part I is here)

During conversations with a couple of co-workers about estimation (after writing this), we were all reminded of strange situations where estimation went haywire. Here’s an example. I was with a small team at a potential client and we had been creating a proposal for a fairly simple project. We intuitively felt that it would take the four of us about 3 months to get done and our high-level estimates validated this guess. However, the project-management team wanted us to break things down into a more granular level, to ensure nothing was missed and so on. Which was fine, and so we did. When we re-estimated the smaller, lower-level tasks, we ended up with a total of 8 months for the same team. No one could really argue with that, the cards were all laid out on the table. We didn’t get the project, a competitor came in and did the project in about four months.

I’ve heard several war-stories that talk of how people break things down, analyze them to death, and then estimate for worst-case scenarios. Then they pad the estimates, sometimes at all levels – at the task-level, at the story-level, and at the project-level. This simply bloats the estimates to a bizarre level. In the case where the estimation is being done by an external vendor, they often risk losing the work. When this is done by an internal, and often captive group, the customer is left with little choice. They budget for the bloated estimate, get the money approved, and end up spending it. After all, no one ever got in a fight with Mr. Parkinson, and won.

We also talked about times where teams spent more time breaking things down and estimating them than they spent to actually implement the darn thing. All fun stuff.

These stories make me think of Heisenberg’s uncertaintly principle – the very act of trying to measure something seems to change it. Obviously this doesn’t quite fit what we’re talking about here, but still… I’ve seen people break things down into minute tasks – and then when they begin to assign time-based estimates to them, they still go with fairly large units of time. Maybe half-day units or sometimes a couple of hours. And then, next thing you know, 2 or 3 simple tasks take up an entire day…

Of course, in certain situations, there is no option – you just have to break things down and make your best guess. This is especially true for vendors bidding for projects. When you’re not in this situation, however, there really is little benefit of taking this approach. Collaborate with your customer instead – do high-level estimates for baseline sizing, get a team together and get your hands dirty, then make claims about when you might be done. This will definitely work better – and will allow the customer to be more involved in the whole process – and they’ll be able to give feedback about what they really want, based on their involvement with the evolving software. In other words, keep it simple – just use your velocity to determine when you might be done. If I have 700 points of work (high-level estimate), and after four iterations I’m doing about 60 points an iteration – I think I’ll be done in another 8 iterations! Quite simple!

And by all means, revise your high-level estimates ever so often if you so wish to do so. Every time something changes or a risk becomes a reality or scope changes or your architecture group changes direction – take another pass at the sizing exercise – and derive a new answer. Just keep it quick and simple, your answer will probably be close enough to the answer you’ll get with more detailed (and more painful and more expensive) analysis.

The trick to this, of course, is to step away from time-based estimation. When people think of time-based estimates, they begin to practice defensive-estimation – and pad estimates “just to be safe”. This is done almost unconsciously, and also quite casually, so much so that it seems perfectly natural. And it adds up. So, by using story points instead, one can easily side-step this issue. The theory is that although the end goal still is to answer the question “what will it take (in terms of time, resources, money)?”, using story-points splits the answer into two parts. The what, and the how much. Story points address the what – by only focusing on the relative complexity of the work. It also has other advantages. The second part of the answer manifests itself after a few iterations – you divide the total number of estimated story points by the team velocity to get an approximate duration. Again, pretty straight-forward.

P.S. – Finally, buffers have their place, since a system with no slack can’t cope with change. However, that is a topic for a different post.
(Part I is here)

Story points – handling unknowns

I’m a big fan of usingstorypoints to estimate effort on software development projects. It is a good way of keeping things simple and it ensures that teams can be efficient and quick about their estimation tasks.

One question that often comes up is how a team ought to handle stories (or epics) that they just don’t know enough about at a given moment. My answer depended on the kind of scale the team was using – if they were using T-Shirt sizing, then the scale ought to have an Unknown Size (translating to a scale of say – XS, S, M, L, and UNKNOWN).

If they’re using a numbered scale, then I suggest a twist on the UNKNOWN level. I’ve recently switched to using a geometric scale (as opposed to a Fibonacci scale) – and to that I’ve added an UNKNOWN level of 1,000,000 points. So now, my scale is – 10, 20, 40, 80, 1000000.

What this does is it radiates a little bit more information about the total estimate for the project. Lets say you have 200 stories, of which 10 are unknown. Lets also say that the rest 190 stories add up to 8450 points. Now, the total (because of the new level for the unknown items) becomes 10,008,450 points. It is still clear that we have about 8450 points of estimated work, but it also makes clear that we have 10 items that are unknowns.

If the unknown level was only twice or thrice or even ten times the size of a Large story, then the total for the project obfuscates how many items are unknown – and gives an impression that is not quite accurate. This large one-million-point level for unknown stories fixes that. And it also effectively broadcasts the idea that a subset of stories just don’t have the same level of detail and clarity as the rest.

Story Points vs. “Real” Hours – The Advantages

This from another recent lunch conversation –

1. Story points are a pure measure of size and complexity>
2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
5. Story points don’t influence behavior (e.g. Parkinson’s Law)
6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.

On a slightly different note –

When you use a geometric series for your story-point scale (say 10, 20, 40, 80, 160) as opposed to, say the fibonacci sequence (1, 2, 3, 5, 8, 13, or multiples thereof), it is a lot easier for your scale to satisfy the closure properties over addition and subtraction. In other words, with a geometric scale, a product owner can say “Hmm… I think this 40 point story is not ready to be played yet”, and you can respond with “How about we swap it with these two 20 pointers?” This could be a bit less intuitive when dealing with the fibonacci scale. All IMHO.

Agile Estimation 2, or Story Points – and why they work

My previous post on estimation sparked off quite a conversation between a colleague and myself. It was a great conversation from which I captured a few points that I wanted to elaborate on.

First of all – what is the psychology behind story points? IMHO, the answer is Parkinson’s law – work expands to fill all available time. This is not a reflection on the ethics or abilities of a developer or anyone else engaged in a software project – but something that, as humans, we’re all susceptible to. Our minds tend to think in terms of reality – and of past experiences. This is why, when asked for an estimate in units of real time, people tend to factor in all kinds of eventualities. It is very difficult not to think in this manner. Keeping the actual timeline outside the scope of the estimation is very helpful – it helps the person doing the estimation think on a somewhat orthogonal dimension – that of complexity alone. This is why thinking in complexity units works so well. You can call them jelly-beans or NUTs (nebulous units of time) or WAG-points if you like.

A related point that I’d like to iterate, if it isn’t already obvious, is that this also helps keeping in check the tendency of folks to buffer estimates. Since the discussion is no longer in terms of real time, people aren’t so much concerned about being able to finish in the amount of time they’re assigning a story is worth or that they’d later have to stick to. Automatically, this helps in keeping buffers out. (Not that buffers are bad – but there should be a method to the buffer madness.)

A side-effect is that teams can quickly agree on complexity estimates. This is especially true when using a simple complexity scale – say Large, Medium, Small. I used this scale and as we gained domain knowledge and experience with the code-base, we added SmallerThanSmall and Tiny. These are worth 200, 100, 50, 20, 8 “points” respectively. I like to use a scale that (almost) doubles as it increases in complexity. Developers with differing levels of experience and domain knowledge can typically agree about where a particular story falls on this scale. This helps taking another subjective factor out of scope for the estimation activity as well – and helps in ensuring all developers can participate.

Finally, from a planning point of view – velocity and simple statistics take care of things. Despite the fact that developers estimate in story points, planning can be done in real units of time after translating the estimates using historical velocity numbers and applying them across the backlog. This part is almost trivial!

Agile estimation – story points vs. hours

Once again, discussions at work have driven me to write this. This time, the topic of debate (or rather, amusement) is that in an agile team, hours (or days) and not story points are a better way to estimate user stories. I disagree.

Developers are, in general, more aware of the potential complexities that they can run into in the process of implementing a story. Despite this cognizance, it is often hard to predict exactly what these complexities might be. Obviously, if a developer knew the exact nature of the issues that he will run into, he can account for those and predict exactly how much time the work might take. Since this knowledge can never be complete, no developer can determine the exact amount of time needed.

Further, depending on the specific process being used in a given team, it is possible that the developer(s) who estimated a given story is not the one who ends up actually doing the implementation. Different developers have different skill levels and differing amounts of domain-knowledge. This also contributes to the variance in the actual time taken for implementation.

Finally, there are things that developers have no control over – the so called external factors – source-control going down or behaving erratically, having to attend meetings, or having to help another team or another developer on something, and so forth. Someone with critical knowledge could be out on vacation or a key developer could fall sick.

Lets represent actual time taken by a developer to complete a story with the following formula ->
A = function(C, U, E, S, K)
A = actual time
C = an idea of complexity (how difficult something is, and how many tasks there may be),
U = unpleasant technical surprises,
E = external factors,
S = implementing developer skill level,
K = available domain knowledge

Clearly, the only thing that can be “estimated” here is C – an idea of complexity (also based on the “understanding” of the team – whatever that is, and however it can be quantified). Let’s say that we measure this with complexity points (or story points). If we assume that everything else will get averaged out over the duration of the project (which it usually does), then it all comes together quite nicely. This is why story point estimation works.

On the other hand, trying to estimate using hours is like trying to guess the effect of the other four (and possibly more) factors. Trying to estimate in hours is like trying to estimate both the effort needed due to complexity AND the velocity of the people working on the story.

Finally, if I hear someone say that they have a capacity of 400 real hours, that they’re signing up for 600 hours of work and end up completing 500, then in my mind, the 500 hours of work that got done (which can’t be squeezed into 400 real hours) might as well be 500 story points. In fact, you can up the numbers by a factor of 10 so that the team really had 400 real hours (time doesn’t change), they signed up for 6000 points and got 5000 done, it will not change a thing. Story points are story points. The team can call it “ideal hours” or “estimate hours” or whatever they like. As long as they’re not real hours, they’re just like a rose with another name…