Size or Estimate

Estimation, I think, has been one of the biggest problems of mankind. The Software development industry is no exception to this sad reality. We almost never seem to get it right.

The problem with the word "estimate" is that it's personal. It's relative to the person who is estimating. Moreover, it's a unit of time. That is why I prefer "sizing" stories rather than estimating them. Size is a non disputed (standard) unit, which measures the level of complexity involved in developing a piece of functionality, a story. The size is standard across a particular project team.

Pizzas are a great example of standard size. They come in small, medium and large sizes and, given the context of the vendor, the whole world knows what a small pizza means.

Pizza Appetite is the capacity to consume pizzas. A 5 year old will find a small pizza to big to eat. A teenager will probably find it perfectly filling. At 25, I find the small pizza too small. I can comfortably eat a medium pizza (or 2 small pizzas). I am sure there are people I don't know who can eat nothing less than a large pizza (or 4 small pizzas)!!

Stories are like pizzas. Given the context of a project, they have fixed sizes. As a developer spends more time on a project, getting older (and wiser), his/her capacity to develop complex stories increases. And this is where the trouble starts. At the beginning of the project the developer could do 1 small story every day. But now, instead of realizing that he can do a medium story (or 2 small stories) in a day, he begins to think that the medium story is actually a small one. The thing to remember is that the size of the story remains the same. It's just that the developer can now do more complex stuff in a given time.

Complexity points are never to be estimated (in fact they can't be estimated because they are not relative to individuals). In the OLAP terminology, complexity points are the fact. An estimate is a calculation you (as an individual) do when you are looking at them from the Time dimension.

So if you are estimating units of time, it makes sense for you to re-estimate so that you take into account your improved understanding of the system.

When you are sizing stories in complexity points be very careful not to fall in this trap. Re-sizing even sounds wrong anyway.

Functional Goals

After this post, I have had a number of conversations with people about what I really meant by setting functional targets instead of story point (velocity) targets. In one such discussion, I was given an example where someone set a goal to run for 90 minutes!!

At first glance you might not find the last statement worth the exclamation marks at the end of it. But this is exactly the difference between functional targets and velocity targets. I think it's wrong to set a target of running for 90 minutes. The real goal is to burn X number of calories. Or to travel X number of kilometers.

Once you set your goal right, you are open to find better ways of achieving it. If your goal is burning calories, you'd probably do it better (faster) by skipping rope for 30 minutes than by running for 90 minutes.

Now all you have to worry about is

• the rate at which you are actually burning calories AND
  
• what can you do to improve this rate
  

So instead of planning to complete 30 points next iteration (going by yesterday's weather, etc), I'd plan to achieve a set of features and keep optimizing the rate at which I am able to produce features assuming that I never compromise quality in wake of going faster.

Iterationless...

After working in week-long iterations for 2 and a half years, going iterationless left me a little confused on my recent project. Of course when I say iterationless, I mean using extremely small iterations to bring in a flow to stories. Lean? Distributed Lean, maybe?

Firstly, I like the idea of trying something new. The team being small and the project being developed in ruby helps this experiment a lot. There are, however, somethings missing in this way of working. I'll list them down and give my view on each of them in this post.

To realize what we missed, let's look at what we get from iterations. The following are the main motives behind iterations.

1. Celebrate small successes
2. Get regular feedback from clients (showcases)
3. Let the whole team know what we will be focusing on in the next iteration, including the business context around it (Iteration Planning Meeting)
4. Re-estimate stories based on additional information gathered during the earlier development (Iteration Planning Meeting)

So let's see how we are trying to handle each of these situations.

1. Celebrate small successes.
This is very important. To look back and realize that we actually celebrated achieving a story-point targets each iteration, however, now sounds really lame. The moment you move your focus away from finishing a set of stories in a given time TO finishing a set of features and going to production, the world starts making more sense.

I think in this aspect chucking iterations totally makes sense. What this means is you should have a very strong release plan, with frequent (less than a month long) releases.

2. Getting regular feedback from clients
Showcases have nothing to do with iterations. Iterations only provide regularity to showcases. To say that we will do showcases once a week (and do it) is I think good enough.

One thing to beware of is that showcases-bound-to-timelines (once a week) and development-bound-to-releases (of irregular time intervals) can be quite tricky to handle.

3. Let the whole team know what the focus of the next iteration is
Ours being a small (ideal?) team, I don't see too many problems in this area.

4. Re-estimate stories based on new knowledge
This, I thought, was the most important aspect we were missing out. But once you realize that your story point sizing is only relative to any other story you estimated, the world seems much better. This means that as long as your triangulation is correct, you are ok.

One thing that IPMs give us though, is an opportunity for the whole team to estimate together. Right now I am unsure of how important this method is. I am posting a few questions related to this at the end of this post. It'll be great to get some feedback on these.


All in all I think going iterationless is beneficial in terms of:

• Shifting the team's focus from story points to features / business value.
• Letting the team focus on estimating complexity of stories much more clearly.
  

What I am unclear about is estimation.

• If we spend 2 hours every week to estimate together, are we going against lean philosophy?
• On the contrary, if we estimate just-in-time, in smaller groups (pair to work on the story) are we losing the "group touch" to estimation?
• Also if we estimate just-in-time (when we decide to play a story), the business doesn't get an opportunity to re-prioritize based on sizing.

Agile Business Analysts

Yesterday, Craig Brown asked Do we need Agile Business Analysts?. Two and a half years back when I joined ThoughtWorks, I would have said "No, we don't". Today I strongly disagree with the view that Business Analysts can be done away with on Agile projects.

The objective of an Agile project is to provide maximum value to the client as soon as possible.

Now I agree that the ideal situation would be when you have business users & developers who agree and abide by this sentiment. You can happily get rid of the BA in such a situation. Real life, for some reason, is never ideal.

Anyone who has interacted with business users on a medium to large project will have faced situations where it has been hard for the business users to come to a consensus on what they want. Business users are generally representatives of different functions of the organization. Each of them has expectations from the application which more often than not are conflicting. Keeping these users focused on what we set to achieve when we started building the software is what a BA does.

Being on an agile project gives the business users many chances to dream, many chances to make changes. Developers are human too. They dream about technology. While sometimes this can lead to some really cool/unique/usable feature in the product, it can also lead to "overcoolified unnecessities". Now in an ideal situation, all these dreams would come true. Unfortunately, dreams in the real world are bound by budgets & deadlines. Managing these dreams, ideas, changes so as to keep them aligned to the original business objective and deliver most value in the given time and budget is what a BA does.

What agile aims at, is to start minimal and change as required. When a small bug on a story turns out to be a big chunk of enhanced functionality, we create a new story. The tasks mentioned above, along with writing user stories, supporting implementation of the functionality, planning the iterations and releases, testing the developed functionality, etc. together makes for a considerable chunk of work. That's when you create a seperate role called Business Analysts.

Now this role can definitely be performed by developers. In my experience, though, good developers don't really want to do any of this. They want to write good code. That's what they are best at. That's where they will deliver maximum value.

Hence Business Analysts.

StubbornSoft & MammothSoft

I met a couple of villains today
a formidable lot.
StubbornSoft was one of them called,
the other was MammothSoft

StubbornSoft had it's own ways
for the user it didn't care.
MammothSoft would smugly say
"Try, change me if you dare."

In a moment I then realized
my dark and ugly fate.
When both of them cried out to me
Why, come let's integrate

We'll make a heavenly trio they said
our technologies cutting-edge
So smart piece of code as us
there'd ne'er be, we pledge

"I am quite small" to them said I,
"my features are too few.
But I let users do their job
and go home happy too"

"And what do we have to do with that?"
They asked to my dismay
"We were made to make the boss happy
not users anyway..."


Software is for users

Mountains to climb

Business Analysts work closely with the customer. Each new area is a challenge. There are discussions and problems and solutions. Both the analyst and the customer get comfortable with the idea of finding better, simpler solutions. This is especially true for fixed bid projects, as the project is at stake if the analyst fails to find a simpler solution and convince the customer too.

Solving problems is always exciting. For an analyst, this is the juicy part of the job, because no human being can survive for long just writing word documents one after the other. One incentive is customer delight, second is developer delight (scope reduction, etc). Of course the kick that an analyst gets out of solving a problem and offering a relatively simple solution is inexplicable.

However, sometimes it happens so that the analyst gets stuck. There is a complex requirement that he/she gets from the customer and as usual the problem solving starts. The solution however seems complex. The situation is there right in front of him, all the scenarios are known and the functionality required to cover all these scenarios is just simply hugh. So the story is left half way through. More thought is put into the problem in wake of a simpler solution.

What the analyst fails to realize is that there is no simpler solution. Sometimes there's a given amount of work and it just has to be done. The sooner this realization comes, the better.

The time spent on a given story is I think, the best indicator of such a situation. Just measure the average time you take for a story. Probably coupling it up with the dev (complexity) estimate would be even better. So if you are taking much more than this average time, there's somthing wrong.

For Example: You take 6 days to analyze and write a (roughly) 3 point story. If you realize that this one story has gone on for 15 days, it's time to stop and think.

In case of such a situation,

• Firstly, raise the fact and see that the whole team knows about this hugh chunk of work coming. Have a domain session and share your knowledge.



• Secondly, prioritize this area. Change the release plan if required. This will most probably turn out to be a risky area.



• And most importantly, start work as soon as possible. Just write a small, testable story and get the area kicked off. IMHO it is acceptable even if the story doesn't provide much value to the customer. It will provide value to the team by introducing an area.

It's like looking up at a mountain and thinking about a simpler way to reach to the top. Most of the times it's smart to start climbing.

As someone has rightly said, "Thought is supposed to be a guide for action. Not a substitute for it."

How to eat an elephant?

The only way to do that is to cut the elephant into slices. Slices which are small enough to be eaten because the sole purpose of cutting the elephant is to make it possible for humans to eat it.

You'll need a certain number of people to eat a whole elephant anyway. If you make slices small enough, at least they won't feel sick at the end of it.

There is no overhead in the activities of choosing the piece that looks most delicious, putting it in your mouth, chewing it and swallowing it. There is some, but it definitly beats having to swallow the elephant whole.

So don't try to be subjective or pragmatic or take a case by case approach. Don't fool yourself.

Write small stories.