Tag Archives: planning

Planning, whether in a programme, porfolio or project, or just part of product development

Agile has Lists but isn’t Lists

Posted on by

Andrew Vos tweeted (@AndrewVos, 15 Nov 2012):

Hey, guys! Guys. Listen. I found this new agile tool! It’s called “writing stuff down in a list, then doing them one by one”1

Andrew is right, the core of Agile planning is a list. Actually several lists. The product backlog is just a list of high level requirements. A sprint backlog is just a list of tasks to do during the sprint. And, more or less, the team does them one by one from the top priority to lowest priority.

But I disagree with the colleague of mine who said to me a couple of years back “Agile is just managing lists.”
Continue reading →

Fluid Planning and Execution Creates Agility

Posted on by

Thought leaders in the US military are challenging traditional approaches to command and control. These military innovators are proposing a more fluid approach that allows simultaneous planning and execution. It is good to see they are catching up but as an Agile practitioner I already do fluid planning and execution.
Continue reading →

When Buckets Go Bad

Posted on by

I use the term Bucket Planning for Release Planning. The metaphor works because buckets overflow if overfilled. There are risks associated with Release buckets corresponding to Minimum Viable Products (MVP). A large MVP bucket has gone bad and a MVP Bucket that continues to grow is a Bucket gone really bad.
Continue reading →

User Story Dependencies are more Apparent than Real

Posted on by

What do I do when a User Story is dependent on another? Well, the most important thing is, to quote the Hitch Hiker’s guide to the Galaxy, “Don’t Panic!”.

I believe dependencies between User Stories are often over played. Sure there are dependencies but often these don’t require any particular management. But even more common are invented dependencies, i.e. dependencies that are more apparent than real. This means dependencies for me are a bit a of requirements smell, i.e. something to be worried about.
Continue reading →

Reporting Percentage Complete on an Agile Project

Posted on by

What do you do when management asks for a percentage complete on an Agile project? The flippant answer is “tell them the percentage complete”. Agilists reject percentage complete when reporting on low level stuff. But for the project as a whole you can get quite an interesting metric, one that is based on real data, so why not calculate and share it.

Continue reading →

Daily Plan: Stand up to Plan the Day

Posted on by

“Stand up please”. Old habits die hard and because I started Agile with Extreme Programming I “Stand up”, I don’t “Scrum”. Otherwise the two types of meeting are pretty similar. “What have you done since we last met? What will you do before we meet again? Any impediments?”

Great meeting. Wrong questions.

As Mike Cohn explained back in 2006, and Matt Wynne reminded me last year, the daily meeting is a Planning session. It is part of Mike’s planning onion because the aim of the “Stand up” is to develop the plan for the day.
Continue reading →

How to Juggle New Product Development with Operational Demands

Posted on by

You’ve got a product backlog as long as your arm but the system is live and operational demands keep landing on the developers doorstep. What to do?

Many development teams have to cope with operational commitments in addition to their new work. This is inconvenient but reality. Basically you need a mechanism to get operational work through the process despite high priority new development. There are a few mechanisms to enable this.
Continue reading →

Benefits Map: Impact Mapping for Programme Managers

Posted on by

Gojko Adzic has recently published a great book on a technique he calls “Impact Mapping”. Gojko’s Impact Maps are a visualisation of the business drivers and the associated project scope. This means the people doing the work (developers, UX, testers, etc) know what to build but also why they are building the functionality, how the functionality fulfils the business outcome and and who the functionality is for. Love it.

As it happens Programme Managers already have a very similar tool for a similar purpose. Benefits Maps, like Impact Maps, are used to visualise business drivers and associated scope, in this case programme scope. They answer two key questions:

  • Why are we doing the programme?
  • How will we realise the benefits?

The dual function – showing why and how – make Benefits Map high value documents. It also means a Benefits Map can easily morph into the initial Programme Blueprint. For a simple programme the Benefits Map may be the only Blueprint. And the diagram format means it fits on one page. Even in a world where we value “Working software over comprehensive documentation” that one page is worth having.
Continue reading →