How do we do requirements analysis in Agile projects?
Here is the question that I asked several times as a coach while teams start their ‘real’ agile transformation.
In teams that are already on their Agile journey, people spend a good part of first 20% of their overall project time in doing analysis before they start the development/testing iterations.
Is there a right way of requirements gathering? Yes, there are several ways to do requirements gathering.
Most important part is to start a time-boxed release planning. During the release planning, what needs to be built and why the software is required is defined so that all the stakeholders including the business, technologists, analysts, the operations and senior leaders can take a decision to go forward based on the business case and high level plan.
What are the deliverables from the ‘Quick Start / Release Planning’?
- Business Vision and Product Objectives
- Prioritized High Level Requirements (Features broken down to stories & NFRs)
- Technical Approach (Solution including co-existence, data migration, tech stack)
- Release Plan (Iteration plan with some contingency)
- Risks, Issues, Assumptions, Dependencies
- Communication Plan
- Initial Story List
Key Success Factors for such an intense planning are
- The right people and preparation
- The presence and participation of attendees with the appropriate actual customers, business knowledge, technology knowledge, domain expertise and decision-making authority
- Meeting duration being face-to-face (as much as possible or at least on VC)
- Regular feedback from attendees during workshop events
- Clear understanding of business and system goals
- Clear understanding of workshop goals
- Strong processes and facilitation
- Clear plan and just enough to create the artefacts to get work started
- Change in mindset to uncover everything and start with the mantra ‘Just Enough’
First we’ll consider who does requirements analysis in agile projects. It would be the same stakeholders who participated in the initial planning, but the level of involvement would vary based on the state of the project. Initial detailing would need a higher level of time commitment from business and subject matter experts. However, as the product takes shape, their involvement would move towards providing or gathering feedback and take decisions.
So how do we write requirements in Agile?
- Create a list of all the prioritized features that is required based on the vision
- Each feature is broken down to vertically sliced stories that are independent, small and valuable
- For breaking down the feature, you can break it by many ways
- Some of most useful are by personas (who’s using it), positive (& negative) flows, workflows (step 1 ,2), channels of usages (browsers, mobile..), acceptance criteria for the feature
- Each story is recommended to be complete within ½ a day to 8 days including testing and automation to be considered small
- Each story has a set of acceptance criteria to provide the scope on what to expect from the product owner as well as the development team
- Creating a visual story list provides a powerful view to all the stakeholders on what is going to be delivered and ensures that nothing important is missed
Why do we need to writing Vertical Sliced stories?
Vertically sliced stories essentially talks only about the functional output and what needs to be done, without making any assumptions on the technology. Vertically sliced stories also ensure that it can be released to production or to the customers. These stories also provide information on how they are being used by the customers as its written from the users’ perspective.
There are technical stories that may be required before such functional/valuable stories can be written, but care should be taken by the scrum master to keep the number of technical / spike stories to the minimum possible.
Important aspects Technology Leaders need to understand in Agile
- Requirements and Analysis in agile would always have the ‘Just Enough’ philosophy
- With analysis ‘Just Enough’, the product/project would continue to be evolving. With an evolving product, technical debt is an integral part
- It’s critical not to penalize rework in an incremental development
Requirements analysis in Agile is summed up with one word ‘Story’ and it is useful to keep these stories – Crisp, Updated and Valuable and Visual. CUVV
If you need help in writing stories and features, please write to me and I can help you.
