Good Inputs Make Good Outputs - The secret to high velocity Agile teams

While I was first embracing Scrum, I read several articles from Jeff Sutherland describing "hyperproductive" Scrum teams. At the time, I was already disgruntled with Waterfall, RUP, etc. and was really warming up to the Scrum methodology. I felt that Scrum was simply a more effective way to build good software. Additionally, I thought how much better a developer's life would be in such a process. But after reading the adjective hyperproductive, my interest was really piqued. Could software development teams have great lives AND produce at a much higher rate?

So I went forth to conquer. I became Scrum certified, received some coaching, and began leading Scrum teams. During the first 3-4 years of leading Scrum teams, I would classify the projects as “somewhat successful”. My teams created good products, worked on the right features, and, in general, had better lives than they did before. But I couldn't quite get any team into what I would consider hyperproductivity. I think this scenario is common. All too often, teams move to Agile and feel better, but don't notice a significant increase in throughput.

The Change

Once I was about 4 years into Scrum, I started focusing on trying to increase the throughput of my teams. I knew if I tried hard enough I could find the culprit. So I started with all of the Usual Suspects:

Our programming techniques aren't extreme enough - Our development practices were just fine.
We don't spend enough time in Sprint planning - I once spent a full week of Sprint planning – and almost died. That certainly wasn't the solution.
Our Scrum Master (SM) wasn’t removing our obstacles - Hey! Well that was me…
Our Product Owner (PO) wasn't engaged - We had the most engaged, hardest working PO. That clearly wasn’t it.
Dev & QA aren't paying attention - OK this would be a problem, but in my case they were engaged, listening, and participating. But perhaps it was what they were hearing that was flawed.

The Actual Problem - "the What"

I like to think of a software development team as a "feature engine". Its sole purpose in life is to produce great features which benefit the application's various users. Like any engine, this feature engine needs the right kind of inputs, at the right time, containing the right amount of detail. Many times, newcomers to Scrum are liberated by its low-documentation approach. However, low documentation doesn't mean minimal information. Rather, high performing Scrum teams have a very high volume of information flow – taking place in its various forms of discussions, interactions and documentation. In this case, “the what” that we were supposed to be creating was not flowing clearly from the PO to the Team.

OK – now what?

Our team realized that the key to increasing velocity was to focus on the inputs to each sprint. If you too are feeling that your team’s velocity hasn’t been maximized, try one or more of the following suggestions to improve things on the input side.

Add focus to "the What" conversation. Some POs themselves can't help but start talking about "the How". A Scrum Master or Agile coach must keep the PO in "the what" space. The how will only come along once the team has a full understanding of the business need.

Add a Definition of Ready. Most teams have a Definition of Done printed out in their team room. However, only a small subset have a Definition of Ready. All should. A Definition of Ready helps ensure that half-baked stories don't get pulled into Sprint planning - causing confusion and wreaking havoc on a team's velocity and happiness.

Enhance the process for getting to Ready - the 4 Rs. Now that you have defined what Ready means - define a process for getting to ready. I like to follow what I call "the 4 Rs":

Raw - This is an "initial placeholder" user story (US) which generally only includes the title and possibly a supporting sentence or two. It allows the PO or stakeholder to enter the general thought for later refinement.
Refined - In this state, the US has been refined by the PO or stakeholder and includes: a) an appropriate title, b) an adequate description, and c) acceptance criteria.
Reviewed - In this state, the US has been reviewed by one or more team members. The team members have vetted the general requirement and posed needed questions/clarifications back to the PO/stakeholder for response.
Ready - The content of the US is complete, all questions/clarifications have been made, and all acceptance criteria are adequate for development and testing. This US is now ready to be taken into a Sprint planning (or pre-planning) session.

Move the focus to the left on the timeline – Pre-planning. Planning ahead of Sprint planning is the closest thing to a silver bullet for velocity improvement that I've seen. For a 2-3 week sprint, 1 to 1.5 hours of pre-planning should be enough. If you need more time than that, you weren't ready for pre-planning and you need to move your focus even further to the left (getting ready for pre-planning, grooming those Raw & Refined stories).

Think of the requirements process as though your PO is a chef in a Waffle House. Hey, c’mon - I live in Atlanta. WH cooks set the bar for efficiency and accuracy. Anyhow, the chef can't be focused only on serving the current meal at hand (Sprint planning & execution). Instead, the chef must:

Look for recipes for new meals (Raw items)
Shop for the ingredients for future meals (Refined items)
Begin preparing & marinating the next meal (Reviewed items)
Begin cooking the next meal (Ready items)

But don’t go too far. Requirements should still become fully-baked in a just-in-time manner. For requirements metrics, strive for maintaining Refined, Reviewed & Ready queues containing around 1.5-2x Sprint velocity. Each queue will decrease to .5-1x at Sprint planning time, then build back up to 1.5-2x by the next Sprint planning. This is a healthy requirements flow. Most Agile Lifecycle Management (ALM) tools have the ability to add additional states or a Kanban workflow to support these queues.

All of this may sound like I'm promoting heavy documentation or planning – that is not the case. It’s all about increasing the efficiency of the information flow.

Delaying the discussion with the team until the story has been refined increases the efficiency of your feature engine. Efficiency breeds happiness across your team. Happy developers produce more and tend not to leave your project six weeks before a major release.
Pre-planning with the team before Sprint planning allows the PO some time to respond/clarify while the team continues to work. Not only is this much more efficient than a long Sprint planning meeting, it also provides the PO with sufficient time to make the right decision.

The Results

I have used these approaches in the past and they have led to both increases and stabilizations of my team’s velocity. In one particular case, for the first 25 sprints the team averaged 55 story points with a “glass ceiling” around 80. This velocity wasn’t bad, but we knew that we could do better. After implementing some of the above changes related to our inputs, the team’s velocity increased over the next 5 sprints to a new average velocity of 95 and 80 became the new floor. I don’t know if this meets the definition of hyperproductivity, but the business sure was pleased.

Learn about our Agile Solutions