Iterative and Progressive Planning

In an effort to give back to the community I wrote up some quick thoughts on planning, including some links for tools that I use/love, and some that I have created.?Much like climbing Everest, there are many routes to achieving reliable software delivery, this is my approach.

Effective planning for software teams requires three things (1) clear, documented goals (2) a system for documenting the atomic tasks to deliver those goals (3) feedback loops to drive continuous learning and improvement.

Thing #1 Clear documented goals - it almost does not matter what you use here as long as you express clearly the WHAT and WHY of your goals. The scale of your goal(s) and the atomicity of your work will dictate what you use. Could be a product canvas, could be a PRD, could be an Epic template?- you will probably need to use some combination of all of these artifacts to adequately define and document your validated problems, and validated solutions.?

Thing #2 Planning should be progressive and iterative. It should be scaled to the size of the work, and the time horizon in question. I like to start with a simple story map, use it to quickly document outcomes and tasks. Once you have a draft story map you can estimate your work and do capacity planning for your period of delivery. Before you start work copy (think groom and improve) your stories/tasks into a tool for tracking work. My favorite lightweight tool for this is Zenhub?it integrates incredibly well with Github and has just enough process and tracking to give you good data, and then gets out of your way. Note: a good practice is to update your story map for the next phase of delivery on a given feature set, and keep using it quarter over quarter as you improve the released work. You go back and improve release work, right ?!?

Thing #3 A planning feedback loop. I like to track all larger bodies of work (think Epics) in a tracking sheet that contains several key pieces of information. Links and references to WHAT/WHY docs, a short name, an understandable description, the person accountable for delivery, when the epic started, when it finished, calculated cycle time, the sum of the unit of estimation (could be stories or points), a simple bubble chart that ties it all together visually. Feedback loops happen when you later review this sheet when estimating future work, and consider how you might decrease cycle time by delivering smaller batches, doing fewer things better (WIP Limits FTW), or better managing upstream problem/solution definition (scope).?

All together this simple system can be used to define, scope, and plan almost any sort of software project. Once you have it in place you can layer in little extras like design documents, test plans, and more effective capacity planning. Once you have this system in place and running you can tweak things here and there to improve reliable delivery or be able to do WSJF prioritization.