Just in Time details – A refresher
A backlog can contain user stories. And these user stories are just the three C’s as Ron Jeffries stated.
It is written by the Customer and it is so little text that you are forced to Collaborate with the customer because otherwise you do not know what to develop.
The Confirmation enables a team to make a reasonable estimate of the user stories and so we come up with a estimated backlog.
A good thing is that the user stories naturally encourage us from adding requirement details at an early stage. Once the PO selects user stories for the next sprint the necessary details can be added Just In Time, like UI, data specifications, business rules, business process flows etc. People need time to add these details, not because the actual writing or describing takes time, but because people need to think about what they want. It is partly a creative process, partly a discovery process and this takes time!
Not all requirements should be written down in full detail, but just enough to have a good start the next sprint! Next to adding details to the scheduled user stories the backlog should also be improved by for example adding new stories, splitting stories from existing epics and estimating any new stories.
So people of the team need to start thinking about some details and adding the details to the selected user stories for next sprint during the current sprint. This of-course interferes with their activities in the current sprint, but the benefits of preparing are often higher then the losses due to e.g. task switching.
In order to start the information transfer to the team members early on, half way the sprint a requirement workshop can be organized to share and learn about the user stories scheduled for next sprint. The result of this workshop is a better mutual understanding within the whole team about what to build and what can be improved prior to the sprint planning meeting. Such a workshop should also result in a set of acceptance examples of how the PO wants to verify that a user story is build in the right way.
An important benefit is that the end result of the user story details are better because the knowledge of the whole team is used. A great side effect is that because the team is involved and contributes to the requirements and therefore the direction of the product to be developed, their responsibility and motivation is increased.
So now the sprint planning will go smoother, concurrent development during the sprint is much easier to do and WIP is under control.
In Scrum btw we expect a team to spent around 10% of a sprint grooming the backlog and preparing for the next sprint.
But isn’t this mini waterfall? No! In waterfall all requirements are detailed before development starts. But even if it was waterfall, so what! Is the goal to not do waterfall?