I've posted previously how I manage burndown charts using a couple of
extra data items in the open source GNATS bug tracking system. It
completely automates real time updating of burndown and integrates bug
fixing with development tasks, while working on multiple simulaneous
projects that generate weekly releases to specific client groups.
Recently, Product Management asked to roll up multiple projects and
show dependencies for them. In their weekly meeting they make
decisions to focus resources on certain releases or functionality.
Those decisions alter all dependencies. They want information that
helps them make decisions and see the impact of those decisions. It is
sort of a Scrum of Scrums decision making group.
After doing some investigation and talking with colleagues running
development in project management software companies, it seemed clear
that Excel cannot easily manage hierarchies of projects. That is
something project management software is designed to do. In order to
stay as lightweight as possible, it was recommended to import
snapshots of burndown data from multiple projects into Microsoft
Project and use this as a visualization tool for Product Management,
as well as a way to do "what-if" analysis.
It was agreed that this abomination should not be inflicted on the
Scrums and no change would be made to their current reporting scheme.
We would report from the bottom up into a management tool for Product
Management to work with.
I'm trying to figure out how best to import the data right now and
give PM what they want. Any suggestions would be welcome.
> Message: 1
> Date: Fri, 28 May 2004 14:10:03 -0000
> From: "Bryan Zarnett" <bzarnett@...>
> Subject: Scrum and Microsoft Project
> Hi Everyone,
> I had an interesting conversation last night with a fellow regarding
> the use of Microsoft Project with Scrum. The fellow wishes to
> implement Scrum but his management core uses MS Project for
> everything. He was wondering how he could integrate the two in short
> term, and see what can evolve in the long term. I just wanted to
> share my comments that I provided him with everyone else.
> 1. Insert two new columns into the project plan. "Duration" will be
> labeled "Initial Estimate" and "Text2" will be labeled "Time
> Remaining". Resource Names will be those individuals "Responsible"
> for the backlog entry. You can add another field "Contact" with the
> label "Originator". This gives you a mock backlog in MS Project.
> 2. You can go even one step better and take each of the 30 "Text"
> fields and label them simply 1 to 30, and these represent the time
> remaining on a daily basis.
> 3. Every day "Export" to CSV file and make sure to date it properly.
> Import it into a named sheet and have an Excel chart representing
> your burn down and voila you have a sprint backlog with a burndown
> chart while using Microsoft Project.
> If anyone is interested, I will post my example MS Project Sprint
> backlog and Project backlogs onto the Scrum Alliance website.
> This is just an example of how to use existing tools to meet the need
> of the job without creating unnessecary problems and impediments.
> If people are wondering, I currently do this now.