Sometimes in Software development, the organization is not quite mature enough to know what we’re going to do. In other organizations there are tons of ideas about what to do, but it’s not written down.

Three People in a Room is a tenet that I coined back in 2012 to describe what needs to happen as a feature/story is generated.

To put it simply, three groups need to be in the represented whenever a decision is made about a feature. Those groups are:

• The idea Owner (typically a product manager)
• The Doer (typically development)
• The Verifier (typically a tester)

It is imperative that these three (3) groups are represented in EVERY conversation and participate in EVERY decision about a feature.

The nature of our support dictates that when our customer calls, we drop what we’re doing to work on the problem.  This keeps our customers happy. And it makes us feel good that we can fix it.

The problem with support is that it cannot be scheduled effectively.  Why?  Because we don’t know how long support will take.

• The actual time could be more than the allocated time. This leads to sprint leakage as properly estimated work cannot be completed.
• The actual time could be less than the allocated time, which leads to either: 1) pulling in random work which may not get completed, 2) spending too much time on stories that are really complete, but we’ll write one more unit test, or 3) twiddling our thumbs.
• Context switching which is hard to do and wastes a lot of time. (cit. Spolsky, cit. Atwood)

A method that I have seen work well in past consultant engagements is to designate a support sprint. In each iteration, one dev team gets the support sprint. That team is essentially “on call”. When not actively engaged in a support call, the team can work on the support backlog (the triaged list of open support/infrastructure/internal bugs). This affords the following:

• Dedicated feature sprints without interruptions (and hopefully less sprint carryover).
• A pool of semi-dedicated resources always at the ready to work those critical severity / high priority issues as they arise.
• A built-in method to whittle down the infrastructure backlog.
• No single team feeling stuck in a support capacity because the support sprint rotates among the teams.

Have you used support sprints in your organization?  I’d like to hear more about how you implemented them and how well or poorly they worked.

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.