It’s Monday. The meeting room’s screen is already on, showing the backlog of your company. A distinctive smell of coffee pervades the entire office. The scrum master and the product owner are already in place. They call in the tech team so they can finally start the weekly sprint planning.
After one and half an hour of continuous discussions, you get out of the room. But there is that feeling… something didn’t go as right as it should. Do you feel that you should be more confident about the predictions you provided? Or that some tasks of the user stories that you were assigned to accomplish, are not what you expected your company’s application should do?
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.
For example, let’s assume that we need to implement the following user story:
Given that a user visits the signup page, they should be able to use Facebook to register, and then provide their email in a textbox
The first way to implement this story is just to accept it and never ask a single question about it.
The second one is to try to understand why we need Facebook register functionality. A developer may suggest that we don’t need an extra step to get the user’s email, because we have already one from Facebook. The product owner may agree or may tell the team that we explicitly need an email for other purposes.
The UI/UX developer may suggest that we move this functionality to the login screen since many web applications use the same page for register and log in using social networks. That seems like a good idea.
Backend developers suggest they add a task to whitelist the production server IPs for security, so no one else can use their Facebook app. Agreed, task added to the sprint.
Do you see how this works? By iterating, discussing, and allowing all team members to say their opinion, a user story may be split into small tasks, update its requirements, or even be removed from the sprint. This may happen because it doesn’t seem like a good fit, either because it needs too much time, or because it doesn’t make sense to implement it anymore. Finally, the team may decide that a story can be split into smaller stories and get implemented in multiple sprints.
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.
At the end of the meeting, you should have a list of user stories that will be implemented, you should have assigned the tasks to developers as well as have exact estimations for each user story. If that’s not the case, give it some more time, your team is going to be faster and better after each iteration.
That’s all for now. Do you have any other tips on how to make the sprint planning process better week by week?
This article was originally published here
If you found this blog post useful, you can subscribe to my newsletter and get to know first about any new posts.
Top comments (0)