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 rituals like standups, retrospectives, demos, and tracking velocity. But there’s one aspect of Scrum in particular that we all 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 sprint planning meeting, we review all of the stories we think we could work on in the next two weeks and determine which stories are the highest priority. This 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 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 meetings, we applied concepts from the Lean/Kanban way of working, where the focus is on limiting work in progress (WIP). Researchers in the manufacturing industry discovered that having too much work in progress 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 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 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 for a magic meeting.
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, the testing approach, the implementation approach, or the design for implementing a 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 it or the customer’s experience in verifying the story — is a lot higher.
Another clear benefit from our experience is the time savings. When our teams used to use Scrum and sprint plannings, we easily spent four team hours per week planning. Currently we average only about two hours per week in magic meetings. On our team with five developers, this translates into ten more hours per week spent actually developing, instead of talking about developing.
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.