Choosing how you will walk through your day, having fun with your colleagues and clients, actively listening and participating in collaborations, and ensuring others also have a great day. I have written a short story a while ago about: The Basics of the Fish! Philosophy for being an outstanding team member. In another blog post, I covered how this can make your Sprint Retrospective more effective. Now let’s have a look at how this benefits your team’s Sprint Planning event.
A small reminder from the Scrum Guide: “The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning answers the following: What can be delivered in the Increment resulting from the upcoming Sprint?, and How will the work needed to deliver the Increment be achieved?” In other words; bring transparency by inspecting the Product Backlog and adaptation (building) the Sprint Goal, a forecast, and the Sprint Backlog. The participants of this session are the full Scrum Team: Product Owner, Development Team and the Scrum Master.
Scenario A:
Sprint Retrospective – check. No real important actions to take. Same as usual. Time for a coffee and then up to the Sprint Planning. Finally, the last Scrum meeting for the day and then back to work.
As usual, the meeting starts ten minutes later because team members trickle in one-by-one. It seems we are starting later each and every time. Well, not that it is a problem. The recommended eight hours in the Scrum Guide is way too long anyway. We now plan for two hours and still have time left.
The Product Owner kicks-off stating “Ok, so you know how it goes. We take the Product Backlog. Pass item-by-item until you guys feel the Sprint is full. Let’s start”.
Item one. Check. Item two. Check. Item three. Check. Oh, there is a question on item two. A small discussion. Nothing of any importance really. The topic is quickly dealt with. The item receives a new estimate doubling the number of man-days, and hop, next item. At item twelve, there is a team member that feels this is the maximum we can do. Not really sure though but hey, if the Product Owner is happy with this, then let’s make this an easy Sprint. Most topics are only for a few people, so that’s great for the others. All team members agree. Done.
And all get out of the room to their desk and can start working.
Scenario B:
The last Sprint Retrospective was really great. There were two clear action points the team committed to experiment with and evaluate again after six weeks. Time for a well-deserved weekend.
On Monday morning, the Scrum Team is back. An important day for all as it is time for the Sprint Planning event.
Ten minutes before the start of the event, some team members are already in the room. There is a buzz in the room already, some chit-chat about their past weekend, smiles, and some pretty loud laughs. Also, some flip charts already on the walls… The team’s Definition of Done is clearly visible. And the Product Owner has hung up a nice image of the Product’s Vision. Someone brought a chart about the Team’s past Velocity. And hey… oh yes, these two action points from the last Sprint Retrospective are also there. The left white wall of the meeting room is almost fully covered with colorful flips. Each team member entering indicates his/her availability for the current Sprint. Seems someone is having a family trip to Spain (while taking a PSM course in Madrid). Another one has a planned health check-up. All-in-all about the same team capacity as previous Sprints.
The Product Owner starts up a conversation about what he would like to see achieved in the next Sprint based on his knowledge of the market. A Development Team member jumps in, indicating that during the last Sprint Review, a stakeholder indeed indicated this was an important topic and that he did some small research in between about it, clarifying a few aspects to the colleagues. A nice surprise for the Product Owner to find out some additional details confirming his understanding of the Chinese market.
As the entire Development Team understands the top items of the Product Backlog pretty well, they can start selecting Product Backlog Items until their capacity is covered. A grid was drawn with as many boxes as there were working days in the Sprint. Product Backlog Items were put on the grid by the day the Team felt they could bring an item to “Done”. This made it all very visual. As Team members would be pairing up, there were for sure items being done in parallel. It felt as a good way to visualize how realistic it is to finish Product Backlog Items.
Once that was cleared out, they agreed on a descriptive Sprint Goal that would guide them during the Sprint.
Ready to move to the “how”. But first… Lunch. The team had agreed earlier that each Sprint another team member would place a reservation for lunch. This time it was… Chinese. What a nice coincidence.
Back in the office, the team split into two groups, each taking two of the highest ordered Product Backlog Items and made a drawing how they would implement the items in the current architecture. They agreed to play a little game: each “miss” found towards the Definition of Done earned a point. After half an hour, each team presented to the others, received feedback, and handled the feedback. And they did this for another round. The score board showed 2-3.
At the end of the afternoon, there were enough items covered to have a good view on what the work to implement these items involved. And the two improvement actions were also included. As the Product Owner was present and heard the short-to-the-point explanations amongst the small groups, he understood how the team intended to implement the selected PBIs (Product Backlog Items) and was more than happy to see their engagement. Sprint Planning objective achieved.
Allow me to assume that you would prefer scenario B. Why is that? It feels straightforward doesn’t it. In fact, in contrast to scenario A, scenario B again implements the four simple practices of the Fish! Philosophy.
Team members “Make Their Day”. For example, a team member having done some research confirming the Product Owner’s understanding of the Chinese market. This was not asked for. It was done. Just like that. By sheer interest. No specific reason.
Challenging each other to discover misses towards the Definition of Done was both constructive and allowed the team to “Play”. Remember that fun brings creativity.
The team is “There” (Be There). They were actively involved. Listening to each other. Challenging each other. Asking questions. Clarifying. They were engaged to create a good plan for the Sprint; to achieve the goal of the Sprint Planning.
And all in all, they did “Choose Your Attitude”. Team members joined on time, well before time, and were prepared. They were working with focus to give a realistic forecast, including features that will be really valuable for the clients. They had the courage to have constructive conversations about tough work. They respected each other’s opinions while challenging or asking clarifications, as they felt the need for it. The context is 100% the same as in scenario A. Yet, they were having fun while working effectively towards their objective. Because they chose to.
Anything you want to change about how your team acts during Sprint Planning events? Let us know, we might help you out, or you can join our next Fish! Philosophy workshop.
Fish! on…
