Follow are a few thoughts on proper agile estimation and planning

Agile principles that apply to this conversation include:

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Business people and developers must work together daily throughout the project.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• The best architectures, requirements, and designs emerge from self-organizing teams.

Here’s examples of how traditional estimation/effort and planning fails:

• The design is done early, but is not documented well enough for the developer to simply pick up and do the work.
• The resulting story is broken down further into smaller stories that provide little or no context, again making it difficult to do the work.
• Acceptance criteria are not defined. How can we prove that the finished product meets the requirement?
• By the time the estimated story gets picked up, several sprints have gone by, and we’ve forgotten what we were doing or why we estimated it the way we did.
• Handoffs add an inherent level of miscommunication. Each hallway conversation, email, written design document, etc. adds noise to the line of communication.

Agile estimation should be limited to a very wide estimation based on level of effort with no design; it is best to leave the low-level analysis and design to the team that picks up the story.

The Agile Estimation Process

The most common Agile Methodology concept is a User Story. It is a simply a written sentence or two that states succinctly what we’re going to do. A story can come from anywhere: customers, product managers, developers, support, etc.. Here is an example of a well written story: “As a bank, I want the flexibility to assign limits and review rules to a user or group of uses each time the user begins a transaction.” Note that the story does not specify how we will achieve this, only what we need.

So let’s discuss the estimation process. The estimation process should be simple and quick. There are three simple steps:

1. Presentation – The story owner (a.k.a. stakeholder) presents the story. It should be written down for everyone to see. In 5 minutes or less, give any background, context, or vision for the story.

2. Discussion – This is where everyone else gets to ask questions. I like to timebox discussions at 5 minutes. Anything longer invites deep design conversations, which are unnecessary at this point. Remember that we are just estimating. We don’t need to design it. Design should be left up to the team that picks up the story in their sprint.

3. Estimation – Everyone votes on how long it will take to implement the story. Usually, the estimation is in some form of time, or effort. If all are not in agreement, others may explain why they think it will take longer/shorter to do the work. This should take no more than 2 minutes.

Introducing 3 People in a Room

Every feature estimation needs to have at least 3 people in the room. This is actually a good rule to follow for ANY conversation about the story.

1. The customer – provides context for the feature. The customer says “We want to do this for these reasons”

2. The developer – understands software architecture, provides design advice.

3. The tester – understands the what and how of the design, so that we can prove that it works. The tester provides valuable insight into how long it will take to proof a feature.