A good preparation is important
Preparation takes time but is important to have a fluid Sprint and keep team focused in delivering. Also it force you to completely determine what has to be done. Though agile method encourage flexibility at middle term. At short term the Sprint level it force to be more rigorous and evacuate uncertainty, bad comprehension…
Preparation is a continuous task
Preparation of user stories can be prepared in advance and user stories can be dropped to future Sprint.
- Easier as you do not need to block a full day for that
- the team can see and help you evaluate what problem could be missing for the user story to be ready
- hierarchize tasks is better done with several estimation as we rarely have a good point of view from the start
So ideally you should maintain a preparation of 2-3 Sprint ahead of current one. Of course that depend of the size of your team and the capacity to dedicate time to preparation.
Also try the iterative approach. First create the user story title then add more details when you know more and can dedicate time. Generally the delivery team won’t dive into the full user story description before the story being in the current Sprint so the title is enough to anticipate a task to do and articulate it with current schedule.
User stories need to be ready
What is ready ? This is something to be defined clearly between the delivery team, the product owner, the scrum master.
This is the definition of ready or DoR.
You can keep with simple principles :
The user story purpose for the product owner should be clearly identified with a formulation like : as a user —- I would like —- for —–
Then the implementation should be detailed as much as possible.
A visual, schema or drawing is necessary as it helps really enter in the subject and synthetise what need to be done.
Then an acceptance criteria section that help define a clear level of finishing that is expected. We all know that we can work very long to fine tune things without end. But what is crucial for product owner is important to know and go in that section.
What is Sprint planning practically
1- choose which user stories will be in the current Sprint
Look at your backlog (the list of your user stories) and choose the user stories that have the adecate size to be delivered in a Sprint by your team. Also evaluate which one is more urgent to go out for example because it will help another project stakeholder to react to it.
2- hierarchize user stories and set prioritization
Once you have a bunch of user stories in your sprint. You can organize them by order of importance. Of courses all are supposed to be finished at the end of the Sprint. But we are human, evaluation is a hard job. So better clarify what would be awesome to have done first.
3- evaluate complexity with delivery and do grooming session
With your delivery team (you team that will actually work on the hard tasks in your users stories) you need to evaluate difficulty. We will dedicate an entire article to the way to do it. But just to explain this stage, you need to make the vision of non technical product owner meet the reality of production. Is it hard to do this user story ? How much time it will last ? Is there any blocage, reorganisation of user stories needed ? This is what in scrum is called grooming.
4- when all is ready start the sprint
And finally when all this organization work alone as a product owner then on concertation with the team and the scrum master is done. You can click on the button : start the Sprint ! And your team can start working.
Want to try agile method with one of your architecture projects?