Four phases of agile change:
Challenge: Over the course of the project, a delivery from another team might have a major impact on our schedule–in our example our initial MVP, the entire process for one product, is adapted to a single process step: acceptance of notification. Other teams’ changes can potentially become overwhelming.
Tip: Use architecture models to visualise when your project depends upon deliverables from other teams. Product owners can then choose relevant stories where teams can collaborate in a planned way.
It’s important to agree a shared priority, to prevent changes in the plan, and a short weekly meeting provides a forum for all product owners, architects, and business analysts to monitor dependencies and arrange their collaboration.
Challenge: During the process, business owners want a detailed view of what will be delivered. We have the story map, but it can still be a bit too general and rather static. We need a way to keep business owners informed about status and progress at the user story level.
Tip: As well as the generic story map, we create a story map on the wall, on brown paper. The format is the same as the story map, but more detailed, and it covers the whole process in scope,two sprints in advance.
The team uses this map as a reference point to allocate work. The product owner uses it as a communication tool for the stakeholders. It’s also the reference model for future deliverables.
Challenge: The product owner prioritises user stories from the backlog, which are refined prior to the sprint. However, these refinements often run out of time; it’s important to ensure there’s enough space for them in the schedule.
Tip: There are three steps which we’ve found can bring significant improvements:
Finally, remember the designs business analysts produce are not always well understood by all stakeholders. Sometimes, other visualisations (based on our models) can be useful to seek feedback or share information. A simplified representation of how a case goes through the process can be especially useful in an implementation sprint.
Using the established Agile phasing is a good way to gain an overview of the business analyst’s role in the process, and the value they can add.
For us, the Novius Business Analysis Framework is an important tool. It includes different models which we can combine to suit the unique needs of each project, and ensures the service, the process, and the application functionality are all designed in a coherent way.
Referring to our fictional FIXIT Damage Insurance example, the value added by the business analyst is clear at all four phases of the Agile change process:
Finally, for convenience, here’s a summary of the insights we’ve gleaned during this agile way of working:
There are three steps which can significantly improve the refining process:
The story map is a useful tool that can show you any stories that potentially use the same functionality. You can then delay detailed work on these particular stories until the sprint prior to realisation – working with the product owner and relevant stakeholders to deliver them just in time.
It’s true that business analysis has no formal role in Scrum, SAFe, or other Agile Methodologies. However, considering the above, it seems clear that a business analyst has a lot of value to offer your Agile change process.
If you’d like to know more about our business analysis offer – or the kind of work you could be doing in a business analyst role – I’d love to hear from you.