Hello great people of the world. 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 events and because of this reason, they’re thinking 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 organisations where the management ensures that the current Sprint velocity should match the previous Sprints 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 how often this event is misused, we start 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 the Sprint Planning with the Why
Yes, yes we are pretty much a fan of Simon Sinek’s Start with the Why. In fact, we apply this Start with the Why thinking to our Sprint Planning. One of the thing that we communicated to the Product Owner is, our Product Owner should start the Sprint Planning with the Why. Every Friday, during our weekly company news session our CEO, keep on saying, “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 the Why that our Product Owner need to answer is, “if this is 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 & Outcome Driven NOT Scope/Feature Driven Sprint
The reason why the Sprint is valuable to us because the Sprint Planning is an opportunity for us to calibrate on the same goal or purpose. You can lose sights 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 looking outwards rather than doing tactical work like detailing the User Stories.
Rather than creating the goal near the end of the Sprint, instead we start the Sprint Planning with the Sprint Goal. Before entering the Sprint Planning, the Product Owner must know the Sprint Goal which is the 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 for the Sprint is: to increase traffic from Indonesia by 5%. From the stated Sprint Goal, the Development Team self-organises 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 utilised 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 we are also using Kanban, the Development Team may pull new work into the Sprint as long as it still helps us achieve 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 pulls everyone in the Development Team towards the same direction 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 a 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 how 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. Not only we stopped planning poker, which is not really part of Scrum, we also stopped using velocity. The Kanban metrics and Service Level Expectation (SLE) also makes more sense to the management too 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 hypothesis 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 don’t see the Product Backlog as the requirements that need to be delivered but rather a collection of hypothesis that needs to be validated. The hypothesis will most likely help us achieve the Sprint Goal. And because it is only a hyphothesis, it is quite possible that we are wrong.
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 visualise 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 and engaging. These techniques are not new, we learned it from the amazing Scrum.org 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 or techniques 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.