At Highland, we’re always thinking about how to be more effective in delivering value to our clients. We use the Agile/Lean/Scrum approach to project management, which affords many of the benefits we’re looking for: our teams work collaboratively and efficiently, and we deliver products that exceed our clients’ expectations.
Our team has a combined 50 years of experience in these project methodologies, and overall, we love them. We still use most of the Scrum framework rituals like standups, retrospectives, demos and tracking velocity. But there’s one aspect of Scrum in particular that the entire team felt could be improved upon — sprint planning meetings.
Our experience has shown us that sprint planning meetings are painful for the team. They can take up a lot of time while returning less value for our clients. In a typical upcoming sprint planning meeting, we review all of the stories we think we could work on in the next two-week sprint iteration and determine which stories are the highest priority. A sprint review could take anywhere from two hours to a whole day. Low-priority issues can sit on the shelf for a long time, meaning that when it’s time to finally work on them in the current sprint our understanding of what they are and how they should be built has substantially shifted, meaning there is an increased risk that we are actually building something of low value.
To develop a more effective approach to sprint planning sessions, we applied concepts from the Lean/Kanban way of working, where the focus is on limiting work in progress (WIP) as a key sprint goal. Researchers in the manufacturing industry discovered that having too much work in progress and product backlog is a money-waster and a time-waster. In knowledge work like software development, the work product is really a matter of collective mental clarity and sustained attention. WIP, in our world, scatters mental energy and decreases the value of things we build in much the same way that log jams and capacity issues waste efficiency in a physical manufacturing process.
We limit our work in progress, and improve backlog refinement, by focusing our development efforts on one user story at a time. We assess user stories individually, only when somebody needs something to work on. When a scrum team member has capacity, they pull the highest priority defined story. The team member reviews the story, comes up with questions, thinks about how it’s going to be tested, identifies a design approach, and then asks the rest of their team and stakeholders for a magic meeting.
Discussing Team Plans with Team Members
In the magic meeting, the team member presents their proposed approach. This gives the rest of the team an opportunity to ask questions and resolve any open issues. Once these details have been clarified, the team member who asked for the magic meeting is ready to go.
Magic meetings typically take 5–30 minutes, and can be used at any point in the development process. They can be used to clarify the acceptance criteria, dependencies, the testing approach, the implementation approach, or the design template for implementing an achievable story.
Because magic meetings are short and focused, stories are developed with a greater attention to detail. We’ve found that the quality and accuracy of the story that gets implemented — meaning either the tester’s experience in testing the functionality or the customer’s experience in verifying the story — is a lot higher.
Another clear benefit from our experience is the time savings on the overall amount of work and the agile team's velocity. In terms of metrics, when our teams used to use Scrum and sprint planning, we easily spent four team hours per week planning. Currently we average only about two hours per week in magic meetings. With our development team capacity of five individuals, this translates into ten more hours per week spent actually developing, instead of talking about developing. This allows us to move from the previous sprint to the next sprint having covered a lot more ground, whilst reducing the potential for sprint backlog.
Shifting to Agile Spring Planning
The shift has a been big for us. Work gets done quicker and we are enjoying ourselves more. This is great for Highlanders and for our clients, who continue to see greater returns on their investment in working with us.
