Agility part two: Burndown tips and tricks

Further to my post last week on agile processes, here are more ideas on how to use a burndown chart.

Tip 1: Separate Projects

I’m currently running with two burndown charts: one for my software job, and one for my writing. This makes sense because the only interaction between them is when one steals time away from the other – there is no dependency between any of the tasks in either place.

The software burndown is a text file generated every other week along with my weekly tracking log, while the writing burndown is a spreadsheet. This is my writing burndown chart for the first three weeks after Beltane (or thereabouts – May Day was mid-week and I like to start my sprints on a Monday).

I actually started this burndown a week into the sprint period, hence the blank week at the beginning. I use OpenOffice and LibreOffice for my spreadsheeting needs, but I believe recent Excel versions can read these too.

Tip 2: Keep Sprints Short

I use a two week sprint for my software burndown since that coincides with my working schedule, and a three week sprint on the writing. I’ve seen four week sprints work, but a week is too short – particularly in a team environment, because you always seem to lose a day to sprint planning and if you only five days to work with, then that is large overhead.

The writing case is interesting because of the low daily load – I really can’t expect to spend more than two hours a day on my creative projects, so I tried setting up six week sprints for that so as to be able to achieve a significant amount over a sprint (the six week length would also have matched the period of my progress posts)

However, that was too unwieldy and rather overwhelming – it’s easy to come up with six weeks of work (for example, the “outline all the scenes” task I put in on the above-linked sheet) but breaking down tasks into achievable chunks too far ahead of time is exactly the kind of brittle long term scheduling that this technique is intended to avoid.

Tip 3: Add Tasks For Follow-Up Work

On the Beltane burndown sheet, I have a task “brainstorming” for the New Dawn project which I implemented by scribbling on my Noteboard. When the brainstorms had passed, the follow-up task was to capture the contents of the Noteboard in a more durable form – that could have been a photo, but I wanted a Freemind mind map. So I created a task for that work mid-sprint.

Tip 4: Keep a Backlog

My sheet has an “above the line” and a “below the line” section. Tasks that are active are above the line – all of the formulae operate on a range down to the line boundary – while below the line is the holding area for tasks that have been pushed out of the sprint or which are not yet planned in.

In Agile terms, this is the backlog: tasks which are known to need to be worked on, but which aren’t actually in a sprint yet.

Backlog items may be very specific, or they may be amorphous blobs of work that encompass an entire project. For requirements-driven creative endeavours, this backlog can be very large and may need to be put somewhere else (such as a ticketing system). For generative creativity the backlog is likely to consist of work phases that will need to be started once the current phase is done.

The division between a well-formed backlog and an endless to do list can be fuzzy.

In the example sheet, the “outline all scenes” task used to be above the line. I don’t have any other backlog items on here yet.

Tip 5: Split Tasks That Are too Big

Sometimes tasks are bigger than we think at first, or there are consequential tasks that come out of the initial work.

The “outline all scenes” task I mentioned before was too large and ill-formed to be planned as single task. So I have moved it out of the active task area and am working instead on outlining the different acts of the story. I expect the actual amount of time taken will be equivalent, but having small tasks with specific objectives will be easier to stay motivated on.

Tip 6: Postpone Tasks Which Don’t Fit Any More

If one piece of work takes longer than expected so that there is no longer time in the sprint to complete other tasks, then push those tasks out (ie move them to the backlog).

This was initially what happened to the “outline all scenes” task, although that was malformed for other reasons of course.

Tip 7: Add Tasks For Unexpected Work

Let’s say that I am working on a story and I suddenly have a burning idea for another tale. What I ought to do is to note it down and carry on with the task in hand, but that isn’t always the right approach if the new story is time-sensitive, for example, or if it’s one of those stories that just shoulders all else out of its path shouting “Look at ME!!!”

If you spend an hour or more on this unexpected work, add a task to the burndown to capture that you spent time on that rather than what was planned – even if there is no more work to be done on it. This leads to erratic zeroes floating around, but it’s helpful to me at least to be able to look back and see that I was doing something with my time even if it was not exactly what I had intended.

In the example spreadsheet, the “outline transfer” task was one that I wasn’t really intending to do but it was necessary to put everything I needed in one place. The copying took about an hour and was done in a day’s writing time.

Do you have other task tracking or planning tricks you use to keep yourself on task?

4 Replies to “Agility part two: Burndown tips and tricks”

  1. The main thing do to keep on track (this isn’t why I do it, but it has this effect) is write and publish serially. That way, there is always a strong impetus to write and edit the next scene, rather than get distracted by some fun scene much later on that might or might not ever get used.

    I still write, or at least make notes on those later scenes, but this keeps me focused on building the foundation from the ground, not from midair.

    1. Dunx says:

      Good advice – the more I write the more I realise I am still working on the basics of my storycraft, so a large part of my tracking is keep myself mindful of the process. If you asked me to write a program to d a particular thing I would probably be able to bang it out in a day or two because I already have the structure of such things encoded pretty deeply in my brain, but making interesting stories is something I am in the early stages of learning.

  2. Darrin Mossor says:

    “The division between a well-formed backlog and an endless to do list can be fuzzy.”

    In my experience, a well-formed backlog has two things that an endless to do list does not:
    1. It is regularly ordered in terms of priority (grooming your backlog)
    2. Items on the Backlog should be (roughly) sized sufficiently to make choices between two items based on that rough sizing.

    My to do lists possess neither of those characteristics.

    Now, back to Backlog grooming on my current project at work…

    1. Dunx says:

      “Can be”, Darrin – “can be”! Your description of a good backlog is germane, but not every backlog I’ve worked with has been so well-managed.

Leave a Reply