Discussion Forum > Motivational Record-Keeping Possibility
If: the schedule is arbitrary; and you don't need to estimate when you will finish; and you have a true Mark Forster closed backlog.
Then: Make your burn-down chart in terms of the number of parts you have for each item in the backlog. Add them all up, and that's your total. Every time a part is finished, you tick down 1.
Congrats on finishing that pile!
Then: Make your burn-down chart in terms of the number of parts you have for each item in the backlog. Add them all up, and that's your total. Every time a part is finished, you tick down 1.
Congrats on finishing that pile!
July 15, 2014 at 15:07 |
Alan Baljeu
Alan Baljeu
For any projects (backlogs or otherwise) which are worth this sort of detailed tracking, then the key piece of information is the date of finishing.
This can be worked out for a simple one person project by dividing your estimate of the number of hours' work left in the project by the average number of hours per day you have so far worked on it.
So the three things you need to track are:
1) the number of hours you work on the project each day
2) your estimates of how many hours work are left in the project
3) your estimates of the finishing date
If the finishing date keeps receding over the horizon, then you might want to rethink your priorities.
This can be worked out for a simple one person project by dividing your estimate of the number of hours' work left in the project by the average number of hours per day you have so far worked on it.
So the three things you need to track are:
1) the number of hours you work on the project each day
2) your estimates of how many hours work are left in the project
3) your estimates of the finishing date
If the finishing date keeps receding over the horizon, then you might want to rethink your priorities.
July 16, 2014 at 12:43 |
Mark Forster
Mark Forster
If a line in the backlog takes longer than expected, your time until done goes up. It's easy to focus on that and not see the progress you've made.
Agile Programming uses burnup charts. (Some agile teams do. Others use burndown charts.)
A burndown chart has one line. It starts with total estimated time, and every day you mark your new estimate. This gets wonky. If you start with a 10-hour estimate, then realize one part will take 15 hours, the line goes up, not down. Disheartening.
Other burndown charts start with the total estimate, and every day you mark work done. This is misleading. If you start with 10 hours estimate and work for 10 hours, this chart shows you have finished, even if you learn it will take more time than estimated.
A basic burnup chart has two lines. The top line is the current estimate, which will grow if you discover problems, or shrink if you cut requirements (or delegate, or realize you over-estimated). The bottom line is work done. It only goes up, and eventually meets the top line.
More complicated burnup charts can show whether a multi-step process is flowing smoothly. The top line is widgets to ship. Working from the bottom up, the other lines are: raw material arrived; widgets made; widgets inspected; widgets boxed; widgets shipped. You could divide it even more. If widgets made keeps going up but widgets inspected is constant, the problem is either a slow inspection stage, or the widget-maker is making too many bad widgets, but making them very quickly.
Estimates and measurements can be by several units. I like pieces of paper, inches, or hours. Yes, there are many arguments against hours, but they're easy. If I realize I'm constantly over- (or under-) estimating, I can adjust the total estimate line.
I don't know if it's worth the effort, though, just to keep up enthusiasm for working a backlog. It probably depends on the nature of the backlog. One that has a reasonably constant hours-per-inch ratio won't need it. One that is filled with surprises might.