Upgrade Your Sprint Planning, Gain Engagement from Your Development Team
Ever Sprint goes down better with just a little planning.
Join the DZone community and get the full member experience.Join For Free
It's been a while since I wrote a blog post here. This time I want to share my experience working with Development Teams and a Product Owner at iPrice group who upgraded the way they ran their Sprint planning.
In some teams around the world, the Sprint planning is seen as the most dreaded Scrum event and because of this reason, they're want to drop Sprints. In some teams, the Sprint has been misused by the management to become a mini-Waterfall where the Sprint planning is an opportunity to lock down how much the Development Team should deliver every Sprint. It is not rare to see in some organizations where the management ensures that the current Sprint velocity should match the previous Sprint's velocity and ensure everyone is 100% busy throughout the Sprint. Some teams even try really hard to measure the time allocation for development work vs. support work.
At iPrice, rather than dropping Sprint planning because of how often this event is misused, we started seeing Sprint planning differently and changed the way we run it. We found there is still value in having Sprints. We want the Sprint planning to be one of the most anticipated event rather than the most dreaded event every Sprint.
Start Sprint Planning with the Why
We are fans of Simon Sinek's Start with the Why. In fact, we apply this thinking to our Sprint planning. One of the things that we communicated to the Product Owner is that our Product Owner should start the Sprint planning with the Why. Every Friday, during our weekly company news session, our CEO says, "This month is the best month ever, so the current Sprint should be our best Sprint ever." It is very important in a startup environment to have the attitude where the current Sprint is going to be the best Sprint ever. Every Sprint planning session, the Why that our Product Owner needs to answer is, "If this were going to be your last Sprint, why are you still funding this Sprint?" Nobody ever wants to lose the race so the Why creates the purpose and sets the Sprint direction for everyone in the team.
Goal- and Outcome-Driven, Not Scope-/Feature-Driven
The reason the Sprint is valuable to us is because the Sprint planning is an opportunity to calibrate on the same goal or purpose. You can lose sight and get lost when you are just focusing on flow. Just like in the Scrum Guide, we have a single Product Owner managing a single Product Backlog who works with (currently) six development teams in every single Sprint. We don't want our Product Owner to get bogged down with managing user stories in JIRA. We want our Product Owner to focus on looking outwards rather than doing tactical work like detailing the user stories.
Rather than creating the goal near the end of the Sprint, we start the Sprint planning with the Sprint goal. Before entering the Sprint planning, the Product Owner must know the Sprint goal which is why we are running the current Sprint. And just like any goal it should follow the SMART attributes, that is the Sprint goal must be: Specific, Measurable, Attainable in one Sprint, Relevant with the current business condition and Time-Bounded (in this case the Sprint itself is the time-bound). For example, the Product Owner can say the Sprint Goal is to increase traffic from Indonesia by 5%. From the stated Sprint Goal, the Development Team self-organizes to select the Product Backlog items that most likely helps us meet that Sprint Goal.
Since we are more focused on the goal and the Sprint planning does not become an opportunity to get the team members utilized to 100% capacity, we just create Sprint Backlog enough for the first 3 days of the Sprint. The work for the rest of the Sprint may emerge throughout the Sprint as long as it still helps us meet the Sprint Goal. The Daily Scrum becomes the mini-planning event for the day where new work may emerge.
Our Product Owner's mantra during the Sprint planning is how can we deliver as little output with the highest outcome as possible. Rather than focusing on velocity or delivering as many User Stories as possible, we are more focused on delivering the highest outcome rather than the highest output. Focusing on the Sprint Goal and on the outcome engages everyone in the Development Team during Sprint planning and throughout of the Sprint. The development team members from UX, test engineers, developers and ops is committed to working together to meet the Sprint Goal rather than to meet certain number of outputs or Product Backlog items.
Use Kanban Metrics for Forecasting During Sprint Planning
This year Scrum.org released the Kanban Guide for Scrum Teams to the public freely. Rather than choosing Scrum or Kanban, we started looking into the possibility to mix Kanban with Scrum to add flow into the way we ran Scrum. In August this year, the leaders at iPrice went through Scrum with Kanban training and learned how to use the Kanban metrics for forecasting and for decision making. After the training, every leader in the company started focusing on one Kanban metric that we think really matter, that is the cycle time from concept to cash. Because we are outcome focused, the cycle time from concept to cash helps us to find improvements to enhances the flow of value delivery.
Using the Kanban metrics really helps us to make probabilistic forecasting rather than deterministic estimates during Sprint planning. It saves us a lot of time from playing planning poker which helps us to shorten the duration of the Sprint planning. The Kanban metrics also makes more sense for the management rather than velocity. From our experience, using Scrum with Kanban did not stop our flow, in fact, it enhances our flow. We get flow from using Kanban and we also get the benefit of empiricism from Scrum. From using Scrum and Kanban, we get the best of the two worlds.
Product Backlog Is a List of Hypotheses to Be Validated
If the Sprint Goal is the why we are running the sprint, the Product Backlog is the what to meet that why. We see the Product Backlog as a collection of the hypothesis we want to validate. The hypothesis help us meet the Sprint Goal. The Sprint Goal helps us choose which hypothesis we want to validate this Sprint. During Sprint planning the Development Team choose which hypothesis that is able to bring us closer to the Sprint Goal. Kanban really helps us to visualize the state of every hypothesis throughout the Sprint. That is why during Sprint planning we don't try to fill up our Sprint to 100% capacity because with Kanban we can pull additional hypothesis throughout the Sprint. Kanban, Kanban metrics and Service Level Expectation (SLE) will tell us whether we can or should pull additional hypothesis during the Sprint.
We certainly did not invent any these techniques for running the Sprint planning to be more energetic. We also learned it from the amazing Scrum community. Through retrospection, at the end of every Sprint, we courageously challenge the way we deliver value to our customers today.
Do you have any other hacks that you have done to make Sprint planning the most anticipated event in your team other than the ones we listed above? Please leave a comment below. We certainly want to learn from you. Scrum On.
Published at DZone with permission of Joshua Partogi, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.