Written by Andrew Murphy,
May 5, 2020
According to the 6th principle of the Agile Manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." So, does it mean that managing agile projects in the new world of large-scale remote working is impossible? Our answer is no! In the previous blog, we talked about how we ensure efficient communication with the home-based teams. In this blog, we discuss the important adjustments we’ve made to our remote Sprint Planning meetings as part of our Agile project delivery.
The value of discussions
Getting the Sprint Planning session right sets our teams on the path to deliver on the project goals, giving us the confidence of deploying a good product at the end of the sprint. This meeting is an excellent example of how Agile shifts a project to focusing on discussions rather than documents. Ahead of the meeting, we prepare user stories, our high-level expression of the features required, and store them on our product backlog. At Sprint Planning, the emphasis switches to verbal communication - the Product Owner explains what their priorities are for the current sprint and the development team questions each other on how the features can be delivered. Don't underestimate these discussions, they lead to a deeper understanding of the requirements and get buy-in from the whole team.
Discussions are a vital part of our Agile project deliveryHow different is remote Sprint Planning?
The new realities of remote working has presented some difficulties in keeping the planning discussions as productive and engaging as when everyone used to gather in one room. The planning meetings are all about exchanging views, digging deeper into the requirements, challenging assumptions and brainstorming for better solutions. How do we replicate the usual face-to-face conversations with video conference calls?
To get around the limitations of virtual meetings, we've set some essential rules. Every team member is asked to switch the video on so we can see each other and pick up on visual cues. One of our colleagues commented that challenging opinions or providing constructive criticism is much easier when you see the other person's face. And we don't jump straight to work discussions, allowing some time to chat about personal lives and families. We've noticed that such small talk helps to build trust and make the communication more productive.
The remote working environment has placed more pressure on our ScrumMasters, whose role is to facilitate the planning meeting. In the previous blog, we explained how we've adjusted to using communication channels such as Slack, JIRA Confluence and Miro. Our ScrumMasters not only had to learn how to use these tools more effectively but also master the skills of the online facilitator. It's crucial to make sure that every team member is involved in the discussion, no one is dominating the session, and all participants get heard. At the same time, the ScrumMaster has the responsibility to record the important meeting decisions and stay focused on constructing the sprint plan.
What's our Sprint Planning approach?
We're big fans of Mike Cohn's capacity and commitment-driven approach. Face-to-face or remote, we're still using it as the way to run the show. The appropriate amount of work for a sprint and the team's commitment is based on the team's estimation of its capacity.
As you'd expect, our Sprint Planning sessions focus on the highest priority user stories first. The team breaks them down into Jira tasks and then agrees which stories should be in the current sprint's scope. The team then works through each backlog story until they feel that they've hit their capacity for the sprint.
Our view on commitment in a sprint
As part of the commitment-based approach, we don't dwell too much on Mike's advice of asking "Can we commit?" as we assess each story. We feel that teams can get hung up on whether their 'commitment' is a guarantee. Asking the question for each user story can be counter-productive as it adds too much caution to the estimates and makes the meeting overly formulaic. And in any event, we find that the commitment from the team is implicit as they break down stories into their constituent tasks. We do though ask the team "Can we commit?" at the end of the planning session, after considering the whole sprint scope. Asking once is enough!
How to assess the remote team's sprint capacity?
.png)
An approximate split of working hoursThe team assesses its capacity based on three main factors:
- Plannable time
- Corporate overhead
- Unplanned time.
At Infomentum, we base our planned time on 5 productive hours each day. The remaining 3 hours cover our corporate overhead and unplanned time, such as company meetings and activities like fire drills. Working from home has introduced new factors into the mix like losing internet connection, reduced bandwidth due to children playing online games, interruptions to help with schoolwork and, if you're lucky, the supermarket delivery arriving in the middle of the day.
What does a sprint look like?
Ordinarily, in a two-week sprint, assuming a developer has no other project commitments, we estimate 35 hours of capacity for a single developer. Why 35 hours? We break it down as follows:
- Throughout the sprint a developer will spend a couple of hours taking part in the team’s daily stand-ups.
- Day 1 of the sprint involves a two-hour sprint planning session, so we cut the development capacity in half on the first day.
- Days 2 to 8 are "normal" sprint days with the 5-hour daily capacity.
- Day 9 involves half a day of final bug fixing, sanity testing and preparation for the sprint review on day 10. Therefore, we cut the development capacity in half and reserve the rest for reviewing the backlog for the next sprint.
- The morning of day 10 is reserved for the sprint review or demo, and post-sprint review actions like clarifications on outstanding bug fixes or very high-level estimates on new features.
- And finally, the afternoon of day 10 is reserved for our sprint retrospective.
We understand that working at home for a prolonged time with blurred life-work boundaries, homeschooling, and the stress of isolation could lead to a drop in productivity. Hence, during our planning sessions, we're still trying to understand our new capacity and thoroughly stress test our estimates to commit to a realistic amount of work only.
We keep an eye on how our teams are coping with deliverables to ensure our commitments are achievable. Being truly agile, we'll adjust our approach if needed.
In our next blog, we discuss how we've adjusted our daily stand up to a remote working environment.
