As I refocus on trying to blog more regularly about life as a Product Owner in an Agile software development organization, I want to start out with a set of posts on the topic I planned to write about in the fall as I wound down my series on velocity.  I planned to start my next blog arc discussing planning in Agile development.  Over the past few months the daily demands of my actual job as Product Owner on two different development teams has meant that (as the Agile Manifesto encourages) I have been ‘responding to change’ rather than ‘following a plan’ and so I am only now launching this next arc.

Here’s my plan to write about planning: I want to share a series of ten posts about planning in Agile that start at the widest level and move into the weeds.  At this point the rough topics and titles for these posts are as follows:

1. What’s so hard about Agile planning?
2. The planning onion (or is it a flame?)
3. Listening to the market – outside in
4. Product roadmaps
5. When worlds collide: functionality that impacts across products
6. Sprint planning: how much is too much (or too little)?
7. Incorporating new feedback between and within sprints
8. Planning for today – would Kanban help?
9. Context is crucial but planned work should be in small chunks
10. Use the retrospective to improve future planning

However, this is an Agile plan to talk about Agile planning, and so it may evolve slightly as I write and get feedback – or it may pivot significantly if I learn something that redirects my thinking (talking about shifting plans to write about planning somehow has me thinking of this: http://www.youtube.com/watch?v=U_eZmEiyTo0).  I already know that somewhere in here (maybe as part of several posts and maybe as a separate post itself) I’ll want to talk about incorporating code refactoring and addressing technical debt into the sprint plans and the product backlog.  Given what I know now though these are the set of blogs I plan to write about planning over the next roughly 10 weeks.  I like planning and I like writing so you might think it would be easy to execute on these goals, but in truth it’s not that simple.