Remember a time when you planned your trip at the very last moment ? You plan a trek the last night. Assemble items - tent, sleeping bag, mattress, backpack, jacket, cap and what not. Next morning when you are about to start and putting on your shoes, you realise that your shoes are torn. It's 6 AM and no store is opened. You decide to get a new pair on your way. You finally see a store but they don't have trekking shoes.
What a bad way to ruin your trek !! Today's Newsletter reflects that many things can go wrong in your Sprint Planning. Which is why planning the Sprint is more important than the Sprint Planning.
If you are transitioning into a product role, most of your initial transitioning would focus on developing Agile Leadership. That includes mastering one Agile methodology like Scrum.
Learning Agile and Scrum isn’t that complex. It’s practising those effectively, where it gets tricky. 5 years back, when I was in your shoes, I was learning and practising the art of implementing effective Scrum. Fact - There is no right way to make Scrum effective.
Organisations and teams comprise of people with different skills and behaviours. The right thing to do is to position Scrum and Agile practices which works best for your teams.
I learnt the hard way !! 👇🏽
One day, I was leading a Sprint Planning, where I was sharing the user stories that we had prioritised during the previous refinement meeting. The duration of Sprint Planning was 2 hours for a 2 week sprint. As we were progressing, I got few counter questions on one of the user story that we thought was crystal clear to everyone. This erupted a series of questions and led to the disruption of the planning meeting. Since there were prior engagements in other meetings, we could not extend the planning meeting. It took me entire day to give clarity on the requirements and kick off the sprint.
🚨 LESSON LEARNT 🚨 - Never depend on the Sprint Planning to clarify requirements and get estimates. I learnt it the hard way only after making a chaos.
New start !! 👇🏽
I knew something needs to be done so that the Sprint Planning runs smoothly and that we conclude, as in start the sprint, before ending the planning meeting. That is when I started experimenting with Sprint Refinement meetings. We started to go over requirements iteratively, bringing up questions and finding answers to those. We analysed those at the deepest possible level, making sure everyone is aligned on what problem is the user story resolving and what is the ask. We also estimated the stories to make sure, our prioritised backlog is all set for the planning.
Sprint Refinements by far are the most essential meeting that a Scrum team should attend. Here are 6 things you, as a PO/ PM can do to have effective Sprint Refinement:
For a 2 week sprint, have at-least 1 refinement meeting for 1 hour. If possible, keep 2. Remember, refinement is the time where you can plan for the sprint. If you conduct effective refinement, you can reduce the duration of Sprint Planning.
Make sure you have thought through on the priorities. You do not want to go into refinement or planning without knowing the priorities. The team looks upto you for the priority.
Make sure you partner with your Scrum Master to engage the entire team during refinement. Encourage the team to ask questions. Answer and close the ones that you are absolutely positive about. For the ones you are not sure, address those in the coming refinement. Remember, no user story with an open question should go to the Sprint. This is when product backlog starts to get messy.
Make sure the user stories are estimated. At-least almost all the user stories. Ask your Scrum Master for help.
Share the user stories with the team one day ahead. Even if you are still working on those. This way, the team can review the requirements beforehand and prepare for questions in advance. Another benefit is it helps to time-box the meetings and even reduce the meeting duration, since now the team is already prepared.
Create a separate section in the product backlog that holds the user stories which are through the requirements and estimates. This section is the one to be referred during the Sprint Planning. In my experience, this is super helpful and helped me to keep my backlog organised. This saves a lot of time and helps move the user stories quickly into the active sprint.
CONCLUSION :
Planning the Sprint is important, not the Sprint Planning in the same way as planning for your trek weeks ahead.
If you found this helpful, there are more ways I can help. Learn more
Comments