Over the last few years I have come to recognise an anti-pattern. That being that new and often more complex requirements are requested by stakeholders with the perception that these are indeed less complex. There is often an assumption that these can be immediately ingested, broken into user stories, placed in the Product Backlog, and estimated in an upcoming backlog refinement ceremony.
Very often for less complex and partitioned requirements the simple user story definition process can indeed be understood by the team and follow the normal pattern of tasks in a backlog refinement meeting. Those typical tasks being, adding additional details, creating subtasks and providing estimates. However, the key here is to determine early the level of complexity of the new requirements and act accordingly.
Where the requirements have been captured by stakeholders and identified by the team as being more complex (integration considerations, need to sync with external parties, numerous edge cases etc.) the aim is to highlight these and gain agreement from the development team and stakeholders to discuss this outside of the normal sprint ceremonies.
These more detailed discussions usually take the form of a meeting with the development team, stakeholder(s) and even external teams or third parties on whom there are key dependencies. The tech lead of the project would typically aim to steer the direction of the meeting and in doing so flush out all of the complexities. The ultimate aim is to understand the problem set, sketch out possible solution(s) that the team agree upon and document these. In an ideal scenario the output from this session would be to create also the the user stories or if perceived large enough, the epic, within the project management tool and include this documentation. Such meetings take the form of many names including mini-inception, deep dive, brainstorming, mini-launchpad and others.
The main goals here are multifold and include:
- Gain confidence in a clear understanding of the stakeholder requirements
- Gain approval from stakeholders that the requirements have been understood correctly
- Avoid ‘rabbit hole’ type (non-conclusive) discussions in sprint ceremonies, especially in backlog refinement
- Enable collaboration with the wider organisation including dependent teams and/or external parties.
- Capture the requirements in a format in both supporting documentation and within the project management tool as epics and user stories that can then be reviewed in a subsequent backlog refinement meeting.
