When Points Become Hours

I was recently working on a Story Pointing exercise for one of my customers who is running a Scrum based project using User Stories (for those not familiar with User Stories, Scrum and Story Pointing, please take a look here and here). This exercise took the form of a Planning Poker session (for info on Planning Poker look here). This all works great in theory, but this project had fallen into one particular trap.....

The notion of a Story Point is that it is supposed to be a measure of story size and complexity relative to other stories in the same backlog. So, if I start with a story that I estimate as 2 points then a story that seems twice as big and complex would be 5 points (on a scale 1, 2, 3, 5, 8, 13, 20, 40, 100), while a story half the size and complexity would be 1 point. It shouldn’t be necessary to know exactly how the story will be implemented in order to gauge its size and complexity relative to other stories.

However, this particular project had over time reached a stage whereby a Story Point had become associated with a particular number of hours development and test effort. This is a dangerous situation to get in to, but very easy to achieve - especially on long running projects like this one where a large amount of historic data had been collected supporting this association.

Two specific problems that occur when Story Points become measures of number of hours of implementation effort are:

Solutionising During Story Pointing

People by nature are generally much more comfortable thinking in terms of tasks and how long they will take as opposed to relative size and complexity. Therefore, when there is a link between the two they tend to switch to the more comfortable approach of asking “how long would it take me to do this piece of work?”. Once they have this figured out they then convert this value back to Story Points.

The problem with this is that to answer the ‘how long’ question you have to know what the solution will be. Therefore you have to work out how you would implement the story then break it down into tasks and then estimate these tasks - usually all done in your head in the space of a few minutes. Chances are some tasks will be missed - meaning the estimate is wrong. Also likely is that when a team later comes to implement the story they will pick a different solution (or the best solution might have changed) and therefore come up with a completely different estimate. 

Any Story Points derived in this way are therefore meaningless unless the people estimating the story immediately go out an implement it using the exact solution used during the pointing process.

Unwillingness to Commit

The other problem with linking Story Points and implementation hours is that people then feel that giving a Story Point estimate is a commitment to complete the story in the associated number of hours. If people feel that this commitment will be enforced then they either become unwilling to commit to a Story Point estimate until they have every last detail nailed down - hence nothing gets sized or sizing takes forever. Alternatively they inflate their point estimates by a significant (usually random) amount to account for uncertainty and unknowns and thus the sizes are no longer meaningful. 

So, when a project gets into this situation, how does it get out of it? Unfortunately, the only real way to overcome the association between Story Points and hours is to repoint the entire backlog. Start with a medium size/complexity story that is pretty well understood (but which has not been implemented or estimated) and  pick an arbitrary size somewhere in the middle of the point range chart (say 5 or 8). This ensures there is no starting link between hours and size. Then estimate all other stories relative to this starting story. This could be a major undertaking for a project with a huge backlog - but it's essential in order to move forward.

And, how do you avoid getting into the same situation again? That is fortunately easier: don’t track hours against stories. A Story Point is a measure of size relative to other stories. Hours are a way of measuring the progress of a team within a sprint. There’s no link between the two and trying to put one in place is always a bad idea.

Agile done badly.....sucks!

In this article Peter Viscarola describes why he thinks that the Agile software development methodology sucks. In many cases he’s right, the process he describes does suck - but he’s not actually describing a good Agile process. His experience seems very tainted by the bad interpretation and adoption of Agile that I see in a (sadly large) proportion of companies who have jumped on the agile bandwagon.

Let’s look at some of his points and show that they apply to ‘Agile done bad’ as opposed to ‘Agile done well’...

Peter states:

For the life of me, I do not understand why I would ever want to write code for a complex facility before I have had the chance to design that facility and consider how it will interact with everything else in its environment. ...

But Agile is all about “just writing code.” System architecture? Design? In Agile, that‘s not in the plan. What‘s in the plan is “code it up and see how it works” and “you can fix it in the next sprint.”

I say:

There’s nothing in Agile that says you have to turn off your brain, stop thinking and just churn out mindless code. Just because Agile means you are working in short increments does NOT mean that you can skip the design stage.

The planning session at the beginning of every sprint should primarily be a design session where the team work out the detail of how they are going to complete the sprint’s work. I’ve even seen planning sessions produce UML diagrams, entity models, storyboards and a myriad of other design detail that the team use for the sprint. They are not just about producing a mindless list of estimated tasks!

Additionally, a good agile team will undertake many short design sessions during the sprint. Each time something new is learnt that might challenge the design identified in the planning meeting (such as a TDD session identifying a better approach), the team should breakout around the whiteboard and discuss how this changes the design that the team is working towards.

What about system architecture? interactions? and so on? Well, your agile team should have a good Technical Architect and this person should be spending a proportion of their time thinking about this, ensuring the system architecture is fit for purpose and keeping the bigger picture in their head. They can then feed this into the sprint planning and on-going design to ensure the work being undertaken fits into the wider solution.

Peter states:

And, that brings me to the second thing that makes Agile suck so badly: The whole “estimation” process. Every time somebody insists that I estimate how long it‘s going to take me to implement some particular functionality, and in Agile it‘s not uncommon to have to do these estimates with great precision,...

Why is estimating software development time so hard? Duh! Truthfully, I can’t even estimate with good precision how long it’ll take me to go to store and get a case of beer.”

I say:

I believe this misses the entire point of estimating in an Agile project. We should accept that no estimate can ever be perfect. Even the most skilful estimator can only give a value based on what they currently know. Any unknown or unexpected event that comes along will dictate that the estimate becomes wrong and needs changing.

So, why bother estimating then? The purpose of estimating individual tasks is not to nail down exactly how long everything will take. It’s purpose is to ensure visibility for the current iteration. If things are being completed quicker than expected then the iteration will run out of work so effort needs to be put into planning what extra work to pull in. If things are coming in above estimate then the team knows that there were more unknowns or unplanned events than expected. This means that they might need to change approach, go back and design a bit more or drop some of the planned work from the iteration.

Estimates are about transparent monitoring of progress that lets the team adapt their plans. They’re not about accurately defining exactly how long something will take. Sadly I see too many Scrum Masters/Managers breathing down developer's necks asking why they have spent 1 hour more than estimated on their current task - this is just plain wrong!

But, even if estimates are only a means of achieving transparency it’s still good to get them as good as possible. How do we do this? We eliminate unknowns by using the planning session to design what we are going to do before estimating it. We also have a good BA/TA who has been pre-thinking the big-picture, finding the unknowns and turning them into knowns even before we start detailed planning. Then we only have to deal with the unexpected!

Peter states:

And that leads me to the final Agile precept that fries my potato: User Stories. Every time I hear somebody say “I‘ve entered that as a user story” I want to puke. Why? User stories are just that: Stories. They‘re data. They‘re not wisdom from the ages. ...

...You code to these particular stories. No, you don‘t get a chance to think through the overall experience for any user. This is Agile software development. You don‘t get to think. You‘re not allowed to design. You‘re allowed to “get some code working” so you can try things out. And that code just needs to meet the user stories, and pass the tests that were so lovingly crafted and stored with those stories. Anything else? Well, that‘s for next sprint.

I say:

Any Agile project that just codes user stories purely in isolation from one another or the bigger picture deserves to fail! If this were the Agile process then it would totally suck! Sadly for many Agile teams - and by the looks of it the only ones that Peter has worked on - this is the reality of Agile.

But there is a better (and correct) way. User Stories are a mechanism for describing a particular feature that a user would find valuable. They should not be treated as silver bullet recipe where just coding this story will deliver a great sprint and a great product. You still have to DESIGN what you are going to build to deliver a story. The team must consider how this story will be implemented, how it will fit into the architecture and the bigger solution and the architectural improvements that will be needed. User interaction designers still need to consider how this new feature fits into the UI to ensure a seamless, efficient experience and so on.

Agile is NOT about just taking a User Story and hacking out the minimum code to meet the Conditions of Satisfaction for that one story. It’s about breaking development down into a number of small, more easily managed iterations. Each iteration should deliver one or more User Stories but in doing so it must also consider the evolving System Architecture, must Design each feature thoroughly so that it ‘fits’ properly into the wider system and produce documentation of the features that have been built. You still have to think, plan, design, code, test and consider the bigger picture. You just do it in more manageable chunks.

Peter, if all you have done on agile projects is turn off your brain and hacked out the minimum code required to get a story to pass then I’m not surprised you think Agile sucks. But those projects haven’t been following an agile methodology - they (and you) have just been hacking code.

Addendum

Since writing this I've had a good email debate with Peter Viscarola. In particular he gave me more context about the type of projects he was trying to develop using agile. I think the nature of these projects (very complex and detailed kernel driver work) is not a naturally good fit for the agile approach.

Agile is no silver bullet - it's just another tool in your toolkit. You have to select the correct tool for the job and use it in the correct way. Sometimes you don't have a nail to knock in so picking the same trusty hammer is not the best solution. However, other times you do have a nail and the trusty hammer is the right tool. I still believe it's wrong to say that agile sucks when its being used incorrectly or for the wrong purpose.

Agile can work on complex projects such as Peter's, but you have to accept longer sprints (4-6 weeks) as two weeks is just too short to build complex features. Secondly, User Stories is probably not the best way to specify kernel driver features. Finally, projects such as these usually need a couple of technical spikes with senior architects to define the high-level architecture and concepts. Full team sprints can then be used to provide the implementation of these concepts.