/home/dkramer

David Kramer's high-entropy blog

Project/Program Planning In Agile

I had a conversation with a client while doing some Agile Coaching about tools for Gantt charts. The conversation turned into a discussion of why Gantt charts don’t support Agile values, so even if it COULD be created, it shouldn’t. Here are some elements from that discussion:

The whole concept of a Gantt chart assumes you have near perfect knowledge of what exactly will be done and how long it will take for the next few months, and Agile is all about reevaluating the current state, where you are going, and what is left to do after each iteration, which is why Gantt charts are not generally used much in Agile organizations. The more appropriate tools would be would be a story map and roadmap, which are not as numerical as a Gantt chart. The fact that a Gantt Chart is built on a mathematical calculation means that its predictions are treated more literally, and sometimes more final, than story maps and roadmaps, which are seen as the current plan.

Even in Agile you need to plan out when you expect things to happen. You can think of a roadmap as a Gantt chart that focuses less on predicted hours for each story and more on an overall estimate of what functionality is expected when, and a story map as the “dependency tree” for the stories and tying them into what value they are delivering. You can start by laying out the stories into groups of functionality and when they will be done, then come up with estimates for when each of those groups will be done. But frankly trying to calculate it from the estimated hours for each story (if every story even has an estimated number of hours) is generally considered to have little relation to what actually eventually happens over the life of the project. Another problem is when you try to calculate this out, people put too much faith in those estimates that can be months out and treat them as promises instead of the current view.

The story map helps tell not only what stories have to happen sooner (mostly because of dependencies) but also what value is added at each stage. What can the user do that they couldn’t do before by implementing this story. If you generally put stories in epics, which also tie that features/value add together, then those epics/features become the roadmap, because the story map is more focused on the work to be done over time and the roadmap is more about what functionality is expected at what time. But both are living documents that should be kept updated as reality changes.

We discussed an interesting concept: Confluence has a plugin to create story maps, but you can also create them yourself. Confluence has the ability to make very powerful queries into Jira. If you build out your story map and roadmap in Confluence pages, using JQL to insert lists of stories and epics in the right place, you have a highly maintainable, always up to date view of them. You can use labels to pull in stories, or stories within a particular epic, or some other criteria, or even query specific story numbers (harder to maintain but more flexible).

Share

February 10th, 2019 Posted by | No comments
Categories: Agile |

No Comments »

No comments yet.

Leave a comment

Site info