Step 2: Use Lean Requirements to jump start delivery
Does this sound familiar?
A business analyst is assigned to a small-to-mid-size project and over a period of six months proceeds to create an extensive library of assets that includes the application design document (in Microsoft word), the design of web services, interfaces, and data architecture, a workflow schema, a user interface document, a high-level workflow document, and a detailed user journey that binds all of these assets together. During these six months, no business value has been created because the company is in no way closer to a functional product.
TIME TO VALUE - WATERFALL
And yet the market doesn’t sleep. Requirements start changing prior to the documentation being finished. Word and Excel documents are static—they do not provide support for versioning, change history and thus become difficult to maintain and keep current. Once finished, they’re more than intimidating. Hundreds of pages of detailed charts, inaccessible or difficult for the team to digest. Lastly, all technical and user interface (UI) design decisions within the requirements documentation have been to-date made by a single analyst that operates without the benefit of a cross-functional team or the knowledge they bring to the table.
So, six months, little value, already outdated. Time to try lean requirements. Without diving into too much history you should know that the objective of lean is to maximize customer value while minimizing waste. It goes a way back, Toyota being the pioneer in the automotive space for transforming what Ford was doing with Model T in a new, flexible framework.
There are a couple of rather simple tools within the lean framework that are irreplaceable in our requirements toolkit when building new (or replacing old) software products.
Time to Value – Agile vs. Waterfall
Unlike classic requirement gathering, we start lean workshops as a group. Our primary objective is to arrive at a shared understanding of the deliverable as a team, while including stakeholders and customer needs in the exercise. During the workshop that can be as short as four hours to as long as three days, we establish personas, perform a story mapping exercise, draw user flow diagrams, and go through basic prioritization exercises for the captured scope. Let’s look at each in detail.
User personas capture the nuances of users that will benefit from the software. We keep referencing our personas as we’re adding functionality to the story map and think of how said functionality impacts their routines.
Story mapping is a collaborative process of capturing product requirements from the cross functional team in the workshop. The approach is simple: there are no bad ideas, and your idea must fit on a post-it note. Everyone in the room takes time writing down their thoughts and then adding them to a whiteboard. The PM meanwhile starts eliminating duplicates and grouping ideas into Epics - larger blocks of product functionality.
Once a story map has been established, the team can collaboratively evaluate the complexity of individual stories. Since each story is relatively simple (otherwise it can’t fit on a Post-it note), t-shirt size estimation is used to evaluate the overall impact of each. For example, is a Facebook sign in a small, medium, or extra-large story? Stakeholders can also debate the sequencing of stories, influencing the delivery schedule and building a Release Schedule and Product Roadmap.
Lean requirements are accessible, create a shared understanding, and allow all members of the cross-functional team to contribute their ideas for the product (a team of 10 is better than doing it solo). It’s also low cost, takes only a couple of days, and provides just enough information for the team to start moving and shipping functional software. A side effect of involving senior executives in workshops is that alignment and buy-in happens through participation. You no longer have a project derailment halfway through the project because your sponsor has committed to the scope and schedule in the workshop.
The beauty of Agile, or specifically dual-track Scrum, is that requirements are created just-in-time for delivery of the following sprint. The definition of acceptance criteria on each story is specified during backlog grooming and lives in Jira - a product management tool. Each time requirements or documentation changes, it can be easily updated in a centralized, living repository that everyone on the team has access to.
To summarize, lean requirements help us ship working software over comprehensive documentation, which is one of the cornerstones of the Agile manifesto.