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, Sprint Planning is seen as the most dreaded Scrum event 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 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, 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 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 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
Yes, yes we are fans 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 things that we communicated to the Product Owner is, our Product Owner should start Sprint Planning with the Why. Every Friday, during our weekly company news session, our CEO, kept 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. In every Sprint Planning, the Why that our Product Owner needs 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 is because Sprint Planning is an opportunity for us to collaborate 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 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 Sprint Planning with the Sprint Goal. Before entering 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, which means 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 Sprint Planning does not become an opportunity to get the team members utilized to 100% capacity, we just create Sprint Backlog 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 toward the same direction during Sprint Planning and throughout 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. Rather than choosing Scrum or Kanban, we started looking into how to use Kanban with Scrum to add flow into the way we run Scrum. In August this year, the leaders at iPrice went through Professional Scrum with Kanban (PSK) 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 matters, 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 have we stopped planning poker, which is not really part of Scrum, we also stopped using velocity. The Kanban metrics and Service Level Expectation (SLE) makes more sense to the management team. 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 with Kanban, we get the best of both 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 don't see the Product Backlog as the requirements that need to be delivered, but rather a collection of hypotheses that need to be validated. The hypotheses will most likely help us achieve the Sprint Goal. And because it is only a hypothesis, 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 of these techniques for running 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.
Are you looking for ways to improve the way you deliver value to your customers and improve the way your teams run Sprint Planning? Check out our Scrum.org Professional Scrum Kanban and Professional Scrum Developer course.