Marek Blotny's Blog

In one of the previous post I was writing about estimates and commitments. I felt that this is an important topic because life shows that very often deadlines are beyond our control. I don’t know if it was only me, but I was living in a world where deadlines were always a matter of negotiations between a client and a supplier. Apparently this is not true for web development industry. This surprising (at least for me) truth was uncovered for me very recently when talking with the COO at Cognifide – Stuart Dean.

But if you think about it for a while, it actually makes sense. You have to realize that our clients are typically marketers. And for them, new website is most often only a part of a bigger venture. It can be a launch of a new product, new marketing campaign or some important for given industry conference. So from our client’s point of view all subprojects should end in more or less the same time. If one subproject has a delay then entire venture has a delay. In consequence new product or new campaign will be launched a few weeks later. And a few weeks delay can be converted into money not earned because of it.

Those are the market conditions we are living in. That’s why quite often we don’t have much room to negotiate deadlines. And that’s why the way to win and sign new contract is to come up with a realistic plan to meet those deadlines. Then simply we have to deliver them on time. I know – it’s easy to say, no so easy to do. But also that’s all what it takes to keep clients happy.

If you are a member of development team, sooner or later someone will ask you to estimate something. It can be something small like a bug or task but it can be also something bigger like entire project. Regardless what that is, try to figure out what kind of answer you are expected to give. I don’t mean here that you should be trying to give the “right” estimate. I’m thinking about something different — usually there are two possible types of answers:

1. We need 12 to 18 weeks for this project.
2. We need 4 developers, 1 interface developer and 2 testers to have this project done before …. (some fixed date)

In the first case … you were really asked to give unbiased estimates, deadlines don’t exist for you. Project plan and deadlines will be planned based on estimates and negotiations with a client.

Second type is more interesting. It indicates that estimates are not the final objective, there is something more. Target (deadline) for this project is already set up front. So the real question here is “Can you come up with a plan to meet the deadline?” To answer it you need estimates, to provide a plan it’s good to know how big the project is. However keep in mind that it is only an intermediate step. It’s better to be very careful with this type of questions because even though you were asked for estimates, in fact it was a question about a commitment. By saying that you need given number of people to get something done, you are in fact giving your word that it can be done. If you don’t believe me then let me rephrase the second answer without changing the meaning into something like this “Sure, we can do it before … (some fixed date), we just need a team of 4 devs, 1 interface dev and 2 testers”

That’s why I think whenever someone asks you for estimates, it’s always good to check if the question is really about estimates or maybe it’s about a plan to meet the target.

What’s the relation between estimates and commitment?

Commitment is a promise to finish agreed functionality in given time. It doesn’t have to be the same as estimate. When you truly need to win a contract with a high-profile client then commitment can be more aggressive than estimates. You may assume that this contract will be a first step to a longer relationship and accept higher risk. On the other hand when you know about number of integration points and expect problems with them, you may want to go with more conservative commitment.

There are scenarios where story points can be very handy and using them is beneficial. But before I move to that, one thing has to be clear:

Like it was stated in my previous post “all that business care are man-days and how many is needed to get things done”.

So it’s essential to establish mapping between story points and time, something like this:

1 SP = less then 4h
2 SP = 4 hours to 1 day
3 SP = 1 to 2 days
5 SP = 2 to 4 days
8 SP = 4 to 8 days

It’s important to remember that points are estimates so mapping story point to a single integer is like chasing rainbows. Estimates should be represented by ranges and the same goes for story points.

As a result of this approach engineering team should be able to say for instance that they need 10 to 20 weeks to deliver a project.

Of course at this point range is quite wide. There are a few options to do something about it:

• use historical data for similar projects to compare estimates and the actual time which was needed.
• ask experienced members for an opinion – they might tell you straight away that there is no chance to deliver in 10 weeks.
• simply assume that optimistic scenario (10 weeks) is not very likely

The best part is that after each sprint you will be able to predict more accurately how much more time your team needs to deliver. Even after first 2-3 sprints you should be able to say if you are close to optimistic scenario (10 weeks) or pessimistic (20 weeks).

Story points are about relative size of work

In one of the comments under Mike Cohn’s post I have found great example for usefulness of story points:

One of the most compelling reasons to prefer story points even though it is another way of estimating effort is because it allows individuals of different skills to discuss the relative size of work. My favorite example is of two runners at the start of a trail–one says it will take 5 minutes to run, the other says 10 minutes. Both are right. Those are the amounts of time it will take each to run. There is no time-based argument they can have to settle on the “right number.” However, both can agree that some other trail is twice as long—one runner will be thinking “Yep, 20 minutes” and the other will be thinking “Yep, 10 minutes.” But both can agree “twice as long.”

Using story points to estimate enforces team members to focus on discussing relative size of stories. They just need to define some reference story (for instance worth 2 story points) and other stories compare to it. This way team members don’t wast time arguing about exact number of hours. Story points are not so fain-grained. For mature teams this approach should be much more efficient then estimating directly in hours/days.

One final thought … it’s probably good idea to use story points to estimate user stories but be aware that people might have very different view on what story points represent. Make sure that all members of your team understand story points in the same way.

Concept of story points was always slightly confusing for me so I wasn’t that surprised after reading Mike Cohn’s blog post and comments that definition of story points can vary widely between different people, here a few examples:

• SP should be based on the complexity
• SP is a measure of complexity, effort, and doubt
• SP is a way to measure the size of the requirement, not the time it takes to implement the requirement
• SP are not about the complexity of developing a feature; they are about the effort required to develop a feature
• SP are “size points” and map to time retroactively
• SP do not *equal* hours because points are an estimate
• SP are an estimate of effort (“how much time will this story take?”)

It’s strange that concept which is part of agile planning and estimating for so long can be so confusing and can be understood in so many (sometimes even contradictory) ways.

Maybe definition of story points should be agreed within each team separately? In a similar way as it should be done with definition of ‘Done’ for user stories? Then for one team story point means X and for other team Y?

Personally I don’t think it’s a way to go. Ultimately after planning session we, as a engineering team, are suppose to answer one fundamental question: how much time we need to deliver the project. Therefore it doesn’t matter if you estimate in story points, ideal days, ideal hours or something else. Final outcome has to be in man-days.

If all that business care are man-days and how many is needed to get things done than maybe there is absolutely no point in using story points? Story points are confusing. Maybe we should estimate in man-days and get rid of this additional level of abstraction? I will try to answer that in my next post …