Burn ups - a follow up

In a follow up to my previous post on burn up charts, I sent an email this is adapted from to members of the team. In it I expanded on the use of Burn up charts in tracking progress on multiple release projects. All names have been changed to protect the innocent.

First burn up chart for Project X Vers 1.0.
Interesting information we can glean from this very early chart;
- We can say, with what we know so far, the likely release dates is sometime between Sprint 7 and Sprint 16.
- To increase the accuracy of our forecast release date, we need to spend more time doing workshops to breakdown the epics. This will reduce the gap between “Known scope and “Known worst case”
- More workshops to determine scope means less time to do actual work. (Catch 22)
- This range is due to large number of Epics (proportionally) still to be broken down to stories (8)
- 9 stories delivered is based on Tablet stories so far completed in this sprint of which most were carry overs from last sprint

Unknowns
There are still an unknown number of epics to be added to the backlog. As we get feedback from clients as well as a result of workshops on the Epics we already have in our backlog.

Support tasks adding to backlog
We have 2 Beta clients already and are seeing the impact of “support” tasks already. Onboarding Client A and Client B have added about 3 days worth of team effort so far, with tasks such as configuration, Software installs and the like. We would expect support tasks to increase as people start using the product in anger.


Chart 1: Countdown to commercial launch


Interesting nerdy stuff
In the chart (Countdown to commercial launch)The lines between “Known: worst case”, “ Known + epics” and “Known Scope” run parallel at the moment. This reflects the degree of unknowns buried within the Epics. As we get deeper into the project, these lines ‘should’ start to converge as we do more workshops to break the epics down.

In the burn down chart (countdown to Beta) shown below (from Beta) we can see that ‘actually’ happened, This trend was less obvious as we only started tracking progress once I joined the team around sprint 6-7 (from memory).



Chart 2: Countdown to Beta

That’s it from me.

Comments

Post a Comment

Popular posts from this blog

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.

Image
Earlier this year I ran a survey around ‘release processes’ specifically with companies that follow agile practices. I promised that I would publish the results and apologies for the delay, I have collated the responses below. Thanks to everyone that participated, really appreciate your time and energy. At iflix we're always looking to improve our release processes so it was really great to get so many good responses. We learnt we're not that far apart from our peers out there. We've got a lot to learn of course, some of that comes from hearing from others and some from the mistakes we make. The trick is to make your mistakes small ones and learn fast with minimal disruption to your customers. This survey was run at least 5 months ago, so it’s a snapshot in time.  Most places I have worked change their processes (inspect and adapt!). I've reproduced the responses in their entirety, so it is a bit of a long read. I’ve anonymised the responses somewhat, retaining
Read more

Mission Orders, 6 military principles that can work for agile teams

Yesterday, I was watching a documentary on the "Battle of the bulge" A famous battle in World war 2. The docu makers were investigating German tactics during the battle. Specifically, tactics which had worked so well early in the war, over extended periods of time, towards the end of the war, fell apart after 3-5 days. Early in the war, German officers had Mission Command, that is, Hitler and high command had high trust in their teams. As the war went on, and things started to go wrong, mission command was gradually eroded as trust fell (especially when his officers tried to kill him). Mission command basically means, set the goal, let the teams be responsible for how they are carried out. Training is centred around this, discipline and training carry you through the unexpected, as long as you know the end goal. Effectively, the German high command no longer trusted the lower ranks, and only gave them enough information, goals etc for the immediate goals and set them
Read more