In the previous article “Estimating Product Backlog Items (PBIs): Before or after Prioritizing?“ we talked about the challenges faced when running Estimation and Prioritization phases at Product Backlog level but we didn’t talk about the creation of Product Backlog Items (PBIs) and how difficult is to collect the right feedback from users, in order to generate relevant requirements, and which is the best rhythm to do so.
In this article, we are going to talk about LEAN DESIGN which is a very structured and powerful methodology that Agile teams would probably need to start using more and more.
Depending on the level where an Agile team is working at (Portfolio, Product or Task), the degree of complexity when educing feedback and requirements from users may vary a lot (see the following diagram):
Portfolio Backlog level:At this level the complexity is the highest one due to the high level of incertitude existing when building a new product. “Which are going to be the users of this new product? Which need(s) must be addressed? Among those needs, which are the priority/key ones?…”
Product Backlog level:At this level the complexity starts decreasing but we can still face big challenges. For instance when trying to identify new features on existing products.
Sprint backlog level:At this level, the functional requirements - originating the technical ones to be shipped to Development team - are the ones already compiled and documented within the associated Product Backlog Item (PBI) so, at this specific level, there is no need to retrieve them again from users.
2. Educing efficiently user requirements: LEAN DESIGN
Now that we have identified where the main challenges are when collecting feedback and inferring requirements from users, here are some questions which should be answered:
Is there any methodology or approach to run this analysis in an efficient way?
The answer is “yes” and it’s called LEAN DESIGN.
What’s exactly LEAN DESIGN?
LEAN DESIGN is a methodology which provides with a structured process and tools to ensure that the feedback collected from users is relevant and actionable but at the same time that the associated outputs to be provided to those users are delivered in a regular basis (this is really powerful when defining new products or new features for existing ones).
Here below you will find a brief definition of the workflow and its associated outputs.
In order to achieve that goal, this methodology follows an iterative and incremental approach thanks to the usage of Design Sprint (defined by Jake Knapp in his book “Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days”), which consists of the phases represented in the following diagram:
We will probably dig into the specific tasks associated to each phase in a future article ;)
As mentioned before, the goal of the Design Sprint is NOT to deliver a new product or a new feature but to validate the associated requirements which will be used later as inputs for the future implementation. That’s the reason why the associated outputs are:
- A prototype: It’s not necessary to do a Software prototype as far as the user can understand the logic and the idea behind it (e.g. it can be built in paper)..
- Feedback from user who has validated that prototype: It will be used as input for the next Desing Sprint iteration.
3. Which are the advantages of LEAN DESIGN?
If we compare this methodology with “Classic Design”, the most outstanding advantage of LEAN DESIGN is the fact that the feedback is processed earlier and revisited with certain periodicity so:
- The potential discrepancies between the outputs we have generated and the real needs from users can be identified and mitigated faster.
- In case the idea or requirement is not feasible or profitable it can be discarded soon, so the associated costs and risks will be low compared to the ones generated when using “Classic Design”.
- Users have earlier and better visibility on the new products or features to come, so this can have a positive impact on the user adoption.
4. Can LEAN DESIGN be applied in any context/scenario?
Only when using Iterative and Incremental methodologies at Development level: It doesn’t make sense to use LEAN DESIGN if your Development process follows a classic Waterfall methodology because it means that, by the time a new feature or new product has been implemented, more requirements have been collected and shipped to Development, hence the risk of delivering obsolete features or products is very high!
- The process of educing feedback from users in order to define the requirements for future products or features, is very complex and not an exact science: “Whatever the feedback you collect, the first outputs will never answer the user needs at 100%, so the sooner you validate them the better.”
- LEAN DESIGN methodology provides a structured process and the appropriate tools in order to accomplish successfully that task.
In addition to the references mentioned in this article, here below you will find other useful ones: