Agile planning online: a template for an online board
Sharing our experience on Agile Planning using a virtual board designed to answer our challenges, combining the expertise of our scrum master for a better online collaboration
First of all, I would like to thank Elisa Pinton and Alessandro Banzatti for their support in the writing of this article.
An inspection on our Sprint Planning events
As mentioned in a previous article, we recently took a hard look at our planning practices with the objective to understand what were the biggest challenges that the team members were facing.
We surveyed all our teams and identified some common challenges and issues related to sprint planning. The actions we took included leveraging normal discussions and coaching in the teams, but we also created a dedicated working group made by scrum masters tasked to rethink our planning practices and develop some supporting tools. One of the tools that were developed was a template for a planning board to be used for remote sessions (our standard nowadays). In this article we want to share with you the template. This is not prescriptive; it is just an inspiration based on what we learnt from our teams. In addition, we want to point out that we found particularly useful for newly created internal teams, who also had a limited experience with agile and also needed some coaching with general planning practices.
A new Sprint Planning board for our teams
The template is our answer to the specific challenges we identified, but it also combines the expertise and experience of our scrum masters working with different teams and coaching them to become more and more mature in their agile practices.
We had two inputs to our tool designing process. On one side, we clearly looked at the scrum practices and in particular at the guidance that already exists on Sprint planning. To recap the 3 main topics that need to be discussed in a Sprint Planning are:
1. Why is this Sprint Valuable?
2. What can be done in this Sprint?
3. How will the chosen work get done?
The board therefore needed to be a tool to facilitate the discussions around those 3 topics.
In addition to that, we also needed to address the pain points and challenges raised by our teams. One of the biggest pain points we identified when we surveyed the teams, was the time dedicated to discussing and understanding the Sprint Goal. The second was to have direct support in evaluating sustainability of the plan. This means that the template needed not only to address the three points above but also specifically address these insights.
Product Vision, Product Value and Sprint Goal
The first part of the board is therefore designed so that all team members spend time discussing the product roadmap to make sure everyone has a common understanding of the product vision, strategy, requirement, metrics, etc.…
Once everyone understands the product vision, the board helps the team focusing on the Sprint Goal, spending some time defining the Sprint goal as they understand it. We experimented with different ways of doing this: from the product owner making a proposal and the team discussing it in the case of product teams working on a more defined backlog to a more collaborative session where everybody gets to make their own proposal in the case of a data science prototype, specifically in phases where experimentation of different types of approaches and exploration of different directions is needed. In both cases a moderated discussion is needed to come up with a shared formulation. At the end a single shared Sprint Goal should be defined: all team members should agree to give a clear and simple goal for each Sprint
Having a common Sprint Goal defined by all team members, helps the team to better define their priorities, which makes it easier which User Stories they should work on next.
The Sprint Goal also helps different stakeholders to understand the aim of the sprint.
Next, the team focus on the Product Value: the Product Owner and Team members ask themselves “How this sprint and its Sprint Goal can contribute to the overall product value?”, that is “How does this sprint make the difference for the product and how we will measure it afterwards” and once everyone has discuss about it, a common and final way of measuring value for the specific sprint is defined.
The Sprint tasks
We can start planning the Sprint after everyone has a common understanding of the product roadmap, the sprint goal, and the product value. We plan the Sprint first by identifying the main tasks to be executed to meet the Sprint Goal, by the end of the sprint timebox. Since online working is nowadays the new normal, we found value for the team members to track down also collaborative sessions and so they can be also added to the board. If not already done, the team members also need to all agree on the Sprint Review date, so that everyone participate because the input all the team member is very important to layout the ground of future Sprint.
Tasks are determined based on the Sprint goal, that may be split into week goals. This is a particular practice we introduced. We often work in 3 weeks sprint, which can be quite long. In addition to that, as mentioned above, one of the points we needed to address was the need to coach teams in planning and verifying sustainability of their plans. For these reasons we introduced a weekly view that can better help braking big tasks and big goals into smaller chunks. As a matter of fact, when some tasks are too large, the scrum master prompts the team to split them into multiple tasks or sub-tasks, while looking at the interdependencies among different tasks. The rules are that each task is assigned to a single person and every team member has usually at least one task.
When listing tasks, the Team Members estimate them using (in our cases) a T-SHIRT Sizing estimation model the team has agreed upon. The Scrum Master challenges the team members in balancing the workload over the sprint weeks and over all the members, but always considering tasks dependencies.
Committing to the goals
The last part of the board is an energy check for the team. The objective is to measure sustainability not only looking at the size of the tasks and their numbers but also checking the confidence of each team member. We usually close the session asking everybody to place a dot on a line representing different levels of energy and confidence. The closest to high level energy the highest the confidence level and the excitement for the sprint. It helps to make sure that everybody is committed and that even people who might be shy in a group setting and do not speak up if they disagree on something, get to be recognized and have their chance to discuss their concerns.
Like we said earlier on this is not prescriptive, but a model created from the feedback of our internal survey and what we have learnt over time.
We hope this will add any value in your Agile Planning Journey.
