How many issues do you have?
- Analyze how many mistakes and bugs did your previous sprint end up with. If there’s a recurrent mistake, you have to address it, or the team’s productivity will never increase.
- Did some tasks not get finished properly because you gave bad specifications? Did the tasks get done, but not all the team agrees on what the definition of the word “done” is?
This, and the time your team dedicated to fixing bugs, meetings, and other stuff that does not work should give you a bigger picture of what’s going on.
What was your team’s velocity?
There are many tools that help you measure your team’s velocity, and if you’re not using them yet, you’d better start right now. Even if you don’t use a tool, you can tell that a team’s velocity is lower than expected if it underperforms.
Some teams will work at vastly different speeds. Some teams will show different velocity on different projects. The key to success is giving a team exactly the amount of work they can handle in a sprint.
Update the context
It’s easy to get lost in the endless stream of fixing bugs and adding new features. But this makes you forget about the ultimate goal of a project, satisfied customers.
If you want to reach this goal, you have to know the context.
Update user stories
- Are your user stories written well? If they are, you have to update them regularly. Keep your user stories up to date, and bring in new ones if you need to press on with the product backlog.
Bring up new tasks
No project can be contained with fixing new bugs. You need to press on with new features. This is why you have to take a look at the product features the project owner will want to implement next and work with them.
- Consider the user stories that describe features the owner wants to get in the language your team understands. Work on specifications drafts, find key tasks and estimate the time your team needs to finish them.
Talk to key people
As a mediator between the client and the software development team, you know the only two sides you have to talk to. Here’s what to talk to them about before you hold the meeting.
Update the owner
Contact the owner to report on the progress made during the previous sprint, and the issues you face.
- Ask about their priorities in the tasks for the next sprint. This is what you have to take to the team next.
Talk to the team
- Present the team with the tasks and ask them to come to the meeting with estimates. This allows your meetings to run much better and faster.
- Make sure everyone is informed about the time of the meeting and is comfortable with showing up on time.
Hold the meeting
Some people say the more meetings, the better. This Forbes expert even suggests keeping people engaged every day keeps productivity high.
This may work for some teams, but many people will think that you don’t trust them enough and micromanage them. Checking the progress and wasting half an hour for a daily meeting are very different things.
You should apply the same time-saving approach to sprint planning meetings as well. This is why actually holding the meeting is the last point in the checklist.
Gather all the information you need beforehand so you can minimize the time everyone spends on the meeting, and maximize the time they spend on the project.
Here’s what you should discuss:
- Deciding what to do during the next sprint is not an easy solution. The owner wants as much as possible. The teams differ in their approach. Some teams would protest, some would agree on any number of tasks just to get over with a boring meeting.
- This is why you, as a mediator, should keep the differences between the team and the owner of the project at the lowest level possible, and get both parties to agree on tasks fast.
- Prioritize tasks that need to be done the fastest. Keep them on the top of the list, and ask your team to get them done as soon as possible.
- Break down each user story into a series of tasks. Ideally, you must have done this already, you just need the team to contribute to your ideas and agree on the set of tasks for the sprint.
- Ask your team to estimate the time they need to complete each task. You may need to add about a quarter to that number if the team was not performing well recently.
Once you have the set of tasks you have to complete during the next sprint, you need to decide how are you going to do them. Basically, this means answering the question “Who does what when?”
- Make sure all tasks have proper descriptions and are realistic and testable.
- Distribute story points in whatever way you feel works best. Consult with the whole team to make sure you all agree on how hard each task is.
- Sort the tasks in time. Place the ones that are prioritized first, and work with the team to detect critical dependencies that can slow development.
- Appoint individual tasks to people who will perform them best. Give basic tasks to less experienced members of the team, and hard ones to the middle or senior engineers.
- Agree on acceptance criteria of each task, so that you don’t have to argue about whether the task is completed or not later.
- Give out testing tasks, if testing is done by in-house employers.
- Make sure to include bug fixes as something that takes at least a quarter of all the working hours.
Learn from your mistakes
No sprint planning will go as well as you wish the first time. You have to monitor the things that you and your team are doing wrong to in order to correct them in the next planning event.
Bio: Sam Radbil is the lead writer for ABODO Apartments, an online real estate and apartments marketplace with available apartments from Milwaukee, Wisconsin 1-bedrooms to luxury New York City rentals. Their research and writing has been featured nationally in Curbed, Forbes, Realtor.com, HousingWire and more.