Wasting your time in the Scrum theatre. Part I: Sprint Planning

Executive summary: Does Scrum have a huge meeting overhead, or do we just miss the point? Part I. – Sprint Planning

 

On a scale of one to ten, how much do you like when somebody’s wasting your time? Yeah, I thought so. Doing something just for the sake of doing it very much qualifies as wasting time, and usually leads to destructive dissatisfaction.

In Scrum, several formal occasions of collaboration – the Events – formulate a key part of the framework. These are often perceived as a burden instead of a means to succeed. The reason for this apparent contrast between meeting and working is quite simple: the events often fail to achieve their real purpose beyond “it is part of Scrum” and are concluded without a clear, valuable outcome, resulting in – you’ve guessed it – time wasted. Considering the frequency of these events, the accumulated waste can become unmanageable lightning quick.

This series aims to help you avoid this “Scrum Theatre”, by reminding you of the original intentions of Scrum Events and pointing out some typical pitfalls.

 

Sprint Planning (Part I. & II.)

The Sprint Planning, which is the first Event of the Sprint, or – from another perspective – the last one of the Sprint Boundary Events, can be thought of as a 2-in-1 Event with different purposes. Let’s call these halves Sprint Planning I. and Sprint Planning II.

By the end of Sprint Planning I., the Scrum Team has to reach a common understanding on what’s the most valuable thing to work on in the upcoming Sprint, and why. This culminates in deciding which Product Backlog Items to pull into the Sprint Backlog and setting the Sprint Goal. The key enablers to Planning I. success is a well-refined Product Backlog: Prioritized, with the topmost Product Backlog Items “Ready” to be pulled into the Sprint, i.e. clear, estimated, and fitting the larger context. Yes, having a common understanding of the larger context is important here – if you don’t know where you want to go, you’ll never arrive there. Thus, collaboration between the Product Owner and the Delivery Team plays a crucial role in the success of Sprint Planning I.

Once Sprint Planning I. has achieved its goal, Sprint Planning II. starts immediately (within the same session!). Now that the Delivery Team knows the Sprint Goal and the Sprint Backlog Items for this Sprint, they start to figure out how to deliver the work. As a Delivery Team member, you’ve succeeded in Sprint Planning II. if you have a pretty good idea of what will you do, with whom, and roughly how for the coming few days. This is the case when you have enough clarity and alignment that you are able to start delivering with the other team members immediately as you go back to your desk after the Planning. Planning II. is where self-organization starts for this Sprint. Thus, the Delivery Team members are to star this part of the Event, the Product Owner staying in the background to help them out if needed.

 

When you hear this, be suspicious

“The Sprint Goal is A and B, then C. We may also do a bit of D if we have the time.”
The Sprint Goal allows the Team to have a clear focus and to rally around a single target during the Sprint. It enables people to self-organize as a team. So, if you leave the meeting having no clear, concise Sprint Goal stated, or if you don’t know why the Sprint Goal is what it is, the event was a failure and it will hamper the self-organization attempts of the Delivery Team. The worst materialization of this is when team members are working towards “their own Sprint Goal” individually

“No idea what the PO wants with these stories. It takes a day only to read them.”
When you only have vague guesses about what to achieve, nasty surprises are lurking behind every corner. You should leave with a Sprint Backlog consisting of Backlog Items crisp and clear

“I think you should stretch your boundaries a bit. I’m sure you can squeeze in this story as well.”
When somebody (the PO, external management, or the team itself) wants to push to achieve more, you’ll leave with a Sprint Backlog unrealistically big for the Team to deliver within the Sprint. If you keep pushing, the result will be a drop in quality, sustainability, and morale. It will also yield disrespect towards the Definition of Done, which at the end will reduce clarity and transparency. Don’t stretch – there are better ways to accelerate

“OK, Team, so will you commit to deliver all these by the end of the Sprint?”
Instead of focusing on outcomes (“value”) and being flexible on outputs (“deliverables”) and tasks, some POs put special emphasis on the team committing to the planned output. The danger is that the team will deliver what they said they will, and not what the customer really needs

“No worries, Planning won’t take long. I’ve already prepared your Backlog for the next two Sprints.”
Though the input of the PO is very important, it is the Delivery Team that should pull the items from the Product Backlog, during which exercise the Sprint Goal emerges via conversation. The capacity (“how much can we do?”) and focus (single Sprint Goal) of the team matter just as much as the priority of the Product Backlog Items. The Delivery Team knows these factors better than the PO – after all, they will have to do the work, not the PO. In this sense, the PO should never formulate the Sprint Goal and create the Sprint Backlog up-front by herself

“Let’s sit together after the Planning to figure out what to do.”
If you need yet another meeting after the Planning to figure out what to do, it is safe to say, you missed the objective of Sprint Planning II.

“Do we have enough testing in the Sprint to keep the QA guys busy?” (feel free to replace “testing” and “QA” with any other functional task and role)
The idea is not to keep each team member busy with tasks perfectly matching one’s expertise. That’s called functional separation with resource allocation, which we don’t have in any agile setup. Furthermore, Scrum is about close collaboration, so if team members have different goals and exclusive tickets to work on individually, you dropped Scrum altogether

“Uhh, finally the Planning’s over. Now, which item shall I start working on?”
If you don’t know who is teaming up with whom to resolve which Sprint Backlog Item, the Sprint Planning did not achieve its goal

“Don’t forget to record the work breakdown in Jira. You remember, management wants traceability.”
You do need to break down the Sprint Backlog Items into tasks, but you rarely need to record them in any chosen tool. It’s uncommon that continuously communicating and closely collaborating team members need this level of administration, and so you should ask yourself: Whose needs does this practice serve? Are those needs compatible with the idea of trusted, self-managing teams? If yes, is there a bureaucratically lighter way of achieving the same result?

 

Some of these points might seem tolerable – and indeed they are tolerated in a lot of organizations –, but not in a mature Scrum organization, where you rely on close, cross-functional collaboration, exploration, experimentation and self-management, instead of detailed work plans, monitoring and control, “work architecture” (e.g. work packages, resource planning, task breakdowns, …) and pre-defined, usually functional distribution of work.

 

Check out the Sprint Planning in our Scrum events cheat sheets

 

Links to the other parts of the series:

Part II. – Daily Scrum

Part III. – Sprint Review

Part IV. – Sprint Retrospective and conclusion