Many months ago I started writing a 10-part series on Agile planning (you can read the first post here if you want to catch up; then keep going forward from there to find the other pieces, most of which are tagged as “Planning”). Since that ambitious beginning I got frequently sidetracked and so I never made it past the seventh section of this planned series. Here I want to pick up where I left off and talk about part eight of that original plan. I’ve already discussed the context for Agile product development planning, the importance of listening to the market to discern meaningful problems to solve, and the construction of roadmaps for both an individual product and the broader product portfolio. I wrote about sprint planning (using the two-week iterations that we practice in my current firm as an example) and the need to incorporate new feedback both within and between sprints to ensure that the team is focused on building the most important thing. With this post I want to talk about daily planning.
As a brief side note, I’ve been reading and learning a lot about different approaches to Agile this year. I’ve been to several Scrum Alliance area meetings as well as their Certified Scrum Product Owner training (and I plan to attend their Scrum Master training in the fall with a colleague). If you’ve been reading my blog lately you know I am reading a book about XP entitled The Art of Agile Development. And for both my job and my personal life I have been exploring Kanban as a way to track the progress of items on my plate. Elements from each of these approaches – along with other things I have read or learned about practicing Agile – have informed my own perspectives on this topic.
One key to daily planning is the daily stand-up meeting; Scrum, XP and Kanban all have a version of this as a core practice and it’s not hard to understand why. Having the team meet daily to discuss progress from the day before, expectations for the current day, and impediments that block potential development facilitates the team’s focus on pursuing their sprint goals together. This daily communication promotes collaborative problem solving, assures efficient knowledge transfer as new issues and opportunities arise, and keeps everyone aware of the team’s incremental progress toward the sprint goals and the broader product vision. Brief daily stand-up meetings (even if folks are actually sitting down) serve a number of valuable purposes – including providing a forum to surface questions that can be addressed outside of the meeting itself – but they are crucial in my experience to allowing effective daily planning for the development team.
A second item that I have found very valuable in encouraging daily planning is some sort of visual representation of the team’s progress throughout the sprint. This could be a Kanban board (learn more about these here if you aren’t already familiar with the idea), burndown chart (check out this link if you want more details on these) or some other way of representing what the team is working on and what progress is being made to get each task accomplished. There are plenty of online tools that can provide this visual depiction, allowing even remote teams to have a consistent view of the most important tasks for the sprint and what stage of progress each item is in on any given day. When larger tasks or stories can be broken into daily pieces (or smaller) it becomes even easier to plan for the day and for the team to track its daily progress. Reviewing our Agile board at each morning’s scrum allows the teams I work with not only to decide clearly what will be worked on each day but also to know if we are on track to meet our sprint goals or if instead we need to adjust our plans.
Employing these elements of daily planning and cooperation leads to daily progress toward established goals even as it provides room to respond to changes. With the frequent delivery of working software as a core principle behind Agile development, practices that promote and support daily delivery of incremental steps toward broader product goals play a key role in effective execution. Balancing wider strategic goals for the product lifecycle with tactical daily progress on specific fixes and features facilitates team focus on accomplishing the items most important for success. The discipline of daily planning does not ensure that the team won’t get side tracked of course because in truth it’s not that simple.
How do you make sure that the daily planning does not get derailed and end up in hours of discussion? This is one of the challenge of treating a daily scrum as daily planning session?
Usually daily stand up meetings are time-boxed at 10-15 minutes; if an issue surfaces in that setting that requires further discussion then that gets handled afterward. A good sprint/iteration plan and a team that works closely together doesn’t also need extended daily planning times – just a quick touch base. At least that’s been my experience.