What is Sprint Planning?
Spring planning is needed for the team to negotiate which stories will be tackled within the sprint. This should be decided after reviewing the number of hours available against the number of task hours required. In addition to hours available, the team should understand their velocity/trends as well - but that's another blog altogether.
How is it done?
1. The Product Owner prioritizes the refined sprint backlog stories and clarifies requirements.
2. The team’s “Sprint Budget” is identified – this is the number of available hours the team has to work on during the sprint. Ideally, the dev team is allocated to working 6 hours per day, to account for meetings and other interruptions.
In my Deutsche Bank days, the team would write their names on the whiteboard (stacked, as rows) and the days of the sprint (as columns). Looking at the days, they would write a "6" within their row for all days they would be working at 100% capacity. If there were holidays, PTO, offsite training - those days would be shown as "0". We would count the number of all teammember hours available and notate that as well.
3. Stories are deconstructed into tasks.
As a Product Owner for this group, I taped & prioritized the printed stories / wireframes / gherkins etc. to the whiteboard. Before tasking began, I would review the stories one last time and answer any questions. From there, they would self organize into small groups and tackle the tasking for each of the stories.
4. Tasks are estimated in hours.
6. Add up task hours and deduct them from the Sprint Budget.
7. Commit to the stories the team knows they can get done.
8. Identify several stretch stories just in case the team delivers early.
My DB team was cross functional and "T" shaped. The developers were able to assist with testing as needed, which allowed them to truly own & swarm on work. During the tasking part of this meeting, the Product Owner is not involved although she should be available for any questions that arise. Typically, the ScrumMaster facilitates this session with the team members.
The end result of this session is for the team to:
Benefits of Tasking:
Challenges of Tasking:
As Scrum Masters, we are responsible for having the courage (<-- One of the scrum values) to not only observe, but to also provide tangible, constructive and valuable feedback to our team members as well.
Even if it’s uncomfortable / awkward / scary.
I grew up an only child and was thrilled when praised by my parents, teachers, friends, family etc. Accolades in the form of hugs, paper certificates, applause, shiny gold star stickers or smiles confirmed my value and motivated me to maintain or improve my good work.
As a professional adult, I still bask in the warmth of positive recognition and compliments, but know it’s not always sunshine and daisies. I can recall a conversation with a previous manager/mentor who once asked how I like to receive feedback. I smiled. “Are you familiar with the shit sandwich?”.
The “Shit Sandwich” is built like this: Bread (flattering content) + Meat (unflattering content) + Bread (More flattering content).
Because I’m an extremely sensitive perfectionist and I absolutely hate to disappoint, I respond well to this structure. Although I’d love a delicious glutinous carb only toasted sandwich, I welcome observations and suggestions for further improvement.
My second favorite feedback tool is the SBI, which stands for “Situation, Behavior, Impact”.
According to The Center for Creative Leadership, “When you structure feedback in this way, your people will understand precisely what you are commenting on and why. And when you outline the impact of their behavior on others, you're giving them the chance to reflect on their actions and think about what they need to change. The tool also helps you to avoid making assumptions that could upset the other person and damage your relationship with him or her.”
Here’s a real world example:
During our retrospective yesterday (situation), you were texting on your phone when the other team members were adding sticky notes to the board (behavior). You are highly regarded on this team so when you appear checked out, I’m concerned that other team members will also follow suit. (impact).
For me, the SBI method is easy to apply and helps to provide behavior changes. Also, it allows me to completely consider the what, why and how prior to the conversation.
To find out how they would like their feedback to be given, provide a few options to your team members. By opening the conversation this way, you’ll have a much more engaging and effective discussion.
Just an agile-dork writing about dorky agile things.