Replanning your project with a time machine

I have an amazing time machine that lets me think better about projects. This is part 1 in a series of blog posts exploring the use of a time machine.

Let’s say that you have a project that has been running for a couple of months. Looking back at your issue tracker and other artifacts, you notice that it’s hard to see what has been done and especially how much time remains. You really wish that you had a proper product backlog of what has been done, so you could forecast how the future will be.

Pulling out a mental time machine, you can answer this question. This is how I create a plan that I’d like to travel back in time to give to myself.

  1. Look over the actual features that you have build. If the application is a normal application with a set of web pages, list all the screens.
  2. Which of the screens have features that required extra work, such as integration, search, dialogues or complex business rules? Split the screens that required extra work into one item per work
  3. Which of the work items did you have to substantially change or even throw away all together? Add a work item for each of these events
  4. For each work item, list a rough date when it was completed. If you have know the sprint, that’s okay. Just list the end date of the sprint. If you know the week, that’s great!
  5. Look over the list that you have so far: Are there things that are especially big? Can you find a way to split them? Are there things that are so small that they don’t really count? Can you logically merge some of these together?
  6. Now you’re ready to count the number of work items completed per week.

If we’re lucky, you may come up with a list of 2-5 items done every week. Each of the items has a clear demonstrable effect that could be seen by a customer.

Now you can look at the work ahead of you. Can you find a similar-size items? If you have some sort of screen mockups of the rest of the work you’re interested in, this is a great source of information.

To complete a plan, list a planned completion date for each work item:

  • For past work items, the planned date is the same as the completed date.
  • For future work items, put a planned date that gives the same rate of items per week as in a reasonable interval of the past.

There are many sources of uncertainty still left in such a plan, but it is a quick way to get a reasonable idea of the work ahead.

Copyright © 2015 Johannes Brodwall. All Rights Reserved.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in English, Software Development. Bookmark the permalink.

Comments are closed.