Let’s discuss 5 tips that can help you and your team improve your sprint planning process.
Tip 1: Make the team feel it’s part of the product while planning your sprint
When planning a sprint, the product owner must make sure that everyone is on track about what the company wants to achieve through the projected user stories. And by saying on track, we don’t mean only how the developers should execute the tasks. We also mean that all team members must have a clear understanding of how these user stories will help the company achieve its goals.
This will help your team get a sense of ownership in the product, making it a task that is not just another piece of code, but a part of the product that you can be proud of developing.
Tip 2: Have acceptance criteria in place on each sprint’s story
A new member is coming to your team, and they attend their first sprint planning meeting. You assign them a simple task, from a user story, to give them the opportunity to start exploring your codebase.
In a correctly organized backlog, a new member should be able to pick a user story and know exactly what they have to do to finish their tasks. The best way to achieve this is by having acceptance criteria in the description of the user story.
The acceptance criteria should explain in everyday language, what is the outcome that a user expects to see if they perform a set of predefined actions. This way, the developers have to make sure that every story that they have to develop, passes all the acceptance criteria provided by the product owner.
Tip 3: Define when a task is considered as DONE
Many scrum teams struggle to estimate how much time a user story will take to implement. Sometimes, that’s because the teams don’t have a clear understanding of when a story can be moved to DONE.
Before starting giving scores on each story, make sure you have made clear to everyone when a story is considered as DONE. For example, you could create the following bullets:
- Story has been implemented by the team
- All acceptance tests are passing
- Story has been deployed to the staging server
- Story has been tested by the QA team
This is a simple checklist, that could tell us that a story is considered DONE. It doesn’t really matter what items the checklist contains. The important thing is for everyone to know exactly what these items are.
Personally, I think that a story should be marked as DONE when it has started to give value to the company, but this is another discussion for another post.
Tip 4: Make sprint planning an interactive process between all team members
Sometimes, especially in teams that haven’t used scrum again, the sprint planning process is mainly guided by the product owner. That’s OK, but keep in mind that planning and estimating the time that a user story needs to be implemented, should be an interactive process between all the participants of the scrum meeting.
Tip 5: Don’t rush to finish the sprint planning meeting
If you think that a sprint planning meeting is not worth your time, just don’t use scrum. If you decide to use scrum, take your time, and do the meeting correctly.
I know… sometimes it gets a little bit boring discussing user stories for two hours straight. If that’s the case split the meeting into two parts giving a 15 minutes break. But never rush to finish the meeting. Set a strict timeframe for it, and stay inside that timeframe.
.gif)
0 Comments