Agile estimating and planning is not an art, is a supernatural force that guide us and makes our lives miserable during a project execution with surrealistic delivery dates and weekends in company of our beloved fellas, sleeping in a blanket, near the computer, on a turn based programming day.

Estimation or the fine art of guessing is what is considered the biggest headache of every project and is because somewhere along the line people forget that high-level estimates are guesses, usually are bad and we tend to be optimistic about those.

At the beginning of a project we have too many unknowns that the degree of accuracy is far to be good. Only after building something you can get a better estimation and refine it with time.

So what we need is a way to make estimations that allows us to create budgets, make a plan for the future and remind us that our estimates are guesses, we are not storytellers and the complexities that we can find will be only estimated writing software.

Let’s focus on the steps to follow to make an agile estimation:

Keep it simple

We can think that the best way to do it is create individual stories and make an estimation for each one following the next guesses: Documentation, Analysis, Design, Programming and Testing. We are not so far from the truth but what really makes an agile estimation is relative sizing.

Relative Sizing

When we try to do absolute estimation, it’s impossible to success as we are getting our best guessing, for example, if I ask you what the sizes in cm2 of these two triangles are:

 You cannot truly say the size in cm2 of each but what you can say is that the blue one is 4 times the size of the blue one.

  So estimating how bigger is the blue one respect to the yellow is easier for you, isn’t it? That’s because we are very good at estimating relatively. We call this “relative estimation” and it forms the corner stone of agile planing.

Once we know how fast the team can go and our stories are sized relatively, we can start setting expectations around dates and the velocity of our team will be set up.

Estimates are unit less

It is a common mistake to assign our relative measures to calendar days or hours. We don’t have a unit to track time! Different people think on different speeds.

What we can do is to make a point based system, and say.

1 pt = small task (maybe a day?)

3 pts = medium task (maybe 2 days?)

5 pts = large task (maybe a week?)

etc.

The way to work is to get 3 user stories of different sizes, one with a small estimation (1pt), another one relative to this one with 3pts, and another one big (5pts) just to establish a baseline, with small, medium and large size stories for the project.

Story points are relative values, not fixed. There is no direct correlation between hours and points. Story points are created by and are specific to the team that estimated them, will likely include a degree of complexity that is understood only by the team, and are not absolute. For example, we cannot say that a one point story is equal to 8 hours because stories on this range can vary depending on the tasks assigned to it and maybe can take 10 hours to complete them. Similarly, you cannot compare one team’s story points with another’s with any degree of certainty.

This is really great, but how we can make it even better?

Team Planning

It’s not about what you can estimate, is about what you and your team agree on estimating the value of a user story.

It works like this:

A team estimate is always better than one person.

Now, how to do this more effective and at the same time more fun?

Planning Poker

After you’ve chosen your unit of measurement and established your scale, it’s time to estimate.

Many of the Agile teams where I worked before uses planning poker to estimate the relative size of the stories. This is very popular among agile teams as the objective is to measure subjective estimations taking in consideration the expertise, experience and point of view of all the members in the development team. The key of planning poker is participation of everyone in the team, including designers, architects, developers, even that guy that is just playing Pac Man all day that will participate on the project as a QA tester, everyone.

There are plenty of panning cards in the internet or no so regular shops, even you can make your owns (we will see this in another post). Each card has one of the numbers in your chosen range of story points (1, 2, 3, 5, 8, 13, 21, etc.). Every participant is dealt a “hand” that contains the full range of available story points.

The cards in the deck have numbers on them. A typical deck has cards showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use similar progressions.

At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.

The meeting proceeds as follows:

• A Moderator (Scrum Master), who will not play, chairs the meeting.
• The Product Owner provides a short overview.
• Each individual lays a card face down representing their estimate.
• Everyone calls their cards simultaneously by turning them over.
• People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.
• Repeat the estimation process until a consensus is reached.

Because planning poker expresses estimates in points, it is ideally suited for estimating the product backlog. The sprint backlog, however, should be estimated in hours.

You can use planning poker at the beginning of any project and throughout its lifecycle as new information reveals itself, priorities change, and clarity surfaces.

I hope this post helps you to reconsider the way to make estimations for your projects and avoid bad situations within your team and with your customer.

–  Happy planing! –

Eduardo Ortega