Defining requirements is a crucial first step in the software lifecycle. But writing requirements that change or get thrown out is a waste of time. In manufacturing, the basic technique of avoiding waste is known as "just in time." The just-in-time concept also applies to software requirements. In this tip, I explain why writing requirements just in time makes sense and offer some ways to drive out waste.
Consider a batch of a thousand widgets that have been built, but not painted. When the plant manager decides to do something totally different, the widgets end up on the scrap pile. We see a pile of scrap; the waste is obvious. That's not so when we throw away requirements. There's no pile of scrap for software lifecycle waste; there isn't even any code to throw away -- just a lot of meetings and documents.
Often, documents cost more to create than the widgets.
Software lifecycle: Just-in-time requirements
Years ago I worked on a team that had a delivery problem. Every week, someone would point out that the business analysts had amassed a year and a half of documented requirements, and the technical team was slowing everything down.
Think about that for a moment: The business analysts were working on what we would be doing a year and a half from now.
Only they weren't really doing that. The low-priority items in that eighteen-month inventory would simply never be done. The high-priority requirements, when we got to them 18 months from now, would likely be outdated. So, a newer, junior analyst would be assigned to them, and we would have to start the requirements process all over again.
The word you are looking for here is "waste."
What just-in-time requirements look like
The work that needs to be done right now might be called a phase, a project, iteration or a sprint. That work is different from, and can be separated from, the work that is going to be done later on. In Scrum, we call that work the backlog, and the community spends a great deal of time and effort on the backlog.
Often, documents cost more to create than the widgets.
Here's an idea: Don't do that. Or, at the very least, spend the minimal time possible grooming that backlog. Focus instead on the work to be done right now. At the end of each sprint, ask the question "What are the most important things to work on next?" Define those things, not the entire list. Once the business owners have defined the work that needs to be done now, they can focus on getting the existing work out the door instead of focusing on what the team might be working on six to eight months from now.
Even this model includes a small amount of waste; requirements are batched into an iteration. To make things truly just-in-time, you define the requirement only when a programmer is just about to write code. One way to do this is with The Three Amigos meeting.
The Three Amigos
If the programmer, tester and business analyst each has a different understanding of what should be built, sooner or later there is going to be waste. The Three Amigos meeting is a formal meeting of all three roles to make sure they understand what will be built, and to prevent waste and rework. If the programmers hold this meeting immediately before coding begins, it has the side benefit of delaying the final requirements, making them just-in-time.
Jon Kern, an Agile coach and a co-author of the Agile Manifesto, has a simple way to sum up the goal of a Three Amigos meeting: The developer needs to understand the feature enough to walk out of the room and be able to implement it. Additionally, the QA professional needs to know enough to test the feature, while the business representative needs to be comfortable that the developer and tester understand what it is the business is asking them to build.
There is more to the Three Amigos concept than the story kickoff, or the "test-case creation" meeting. To learn more about it, read the SearchSoftwareQuality interview with George Dinwiddie.
But we need estimates!
The common argument against the just-in-time requirements approach is that "the business needs estimates," and this sounds reasonable on its face. The question is, Estimates at what level of detail, and how will the estimates be used? Agile expert Arlo Belshee suggests that estimates are useful one to two months out, not the typical six to nine months. Belshee believes that once the team measures cycle time -- that is, the average time to move one piece of work from "idea" to "done" -- the product owners have enough information to steer projects.
In the old model, the product owners carefully defined scope six months ahead of time, asked the team to commit, got a "yes" and, six months later, were surprised when the project was late.
Steering is different. To steer, product owners define what to work on next and, based on cycle time, they understand when it will be done. Instead of defining a batch of work, the customer can create a stack of the work to be done next, perhaps five or ten cards long. Programmers ready to take on new work can pull a card from the stack; they might do the detailed design work in a Three Amigos meeting, sometimes called a test-case creation session.
Putting it all together
By deferring exactly what to build until the last responsible moment, business representatives can throw off the burden of unverified, possibly unrealistic requirements and focus on steering the project to success.
To do this, teams have to deal with some degree of uncertainty, changes in priority, and changes in scope. This makes some people uneasy, but the reality is that the uncertainty always existed. It was just hidden.
Given a choice between hiding that reality and steering, I'll pick steering any day. I hope you will, too.