Tag Archives: roadmap

Pair program your roadmap

Posted on by
Doing a road map can be a tricky thing. There are plenty of constraints and dependencies to consider:

  • how to we balance long and short term improvements?
  • how do we rate future revenue opportunities for our clients?
  • how well do the separate steps tie together to a coherent product?
  • is this fun and challenging? are we keeping our team motivated?
  • can we stop half way?

I find that pair programming is by far the fastest way of traversing the decision tree. Basically, if you are a Product Owner, construct the road map together with another person. Lay out the plan that best meets the constraints and business goals and let the other question the options. (Of course, don’t forget to switch).

Altogether, it helps you check  the different options and prepare arguments. You will be better prepared when meeting the stakeholders. For when you do, there is always something uncertain waiting for you.

Scrum in the large – demystify roadmaps and progress tracking

Posted on by

A good thing with Scrum is that it helps the team focus on short term goals instead of dealing with big tasks with dubious value.  But we cannot either resign and give up long range visibility of where we are heading with the excuse of “we are doing Scrum”.

The latter is dangerous since we are not alone in building the business value of software.  Sales, marketing, support, third parties  -all need to work together to make the software a successful business value.

Pull in the same direction

If we only provide "next sprint" visibility your Marketing manager might – after one year silent resistance of your Scrum trial – go ballistic about lack of date visibility and lobby for a return to the waterfall/Gantt approach.

So let’s demystify the roadmap: a roadmap should help you all pull in same direction.

If you can get all surrounding parties to attend your sprint demo and sprint planning, you have come a long way. But in many cases that is impractical, you would simply be to many or you might loose focus (having to explain details of scrum instead of doing actual planning for example).

A typical roadmap would stretch for about six months. If should provide the overall view as of the release dates of your sprints and the expected content (user stories).

The trick is to demystify the date and content relationship.  By providing visibility in the planned dates for the sprints, the actual content in the sprints might actually matter less. You can move to a more fruitful discussion of “what happens if" (we switch the order of sprints, or move this story )..  Instead of  “I have no clue in what you guys are doing” .

A simple roadmap at sprint 1 could look like:

Sprint 1 Roadmap

Now after sprint 2 things change. A new competitor makes us revaluate the sprint content, order tracking switches between sprint 3 and sprint 4:

Roadmap before Sprint 3 

And since we publish the roadmap on a website or accessible place, we no longer need to provide tedious status reports!

Suggestions where to keep your roadmap:

  •     Published to a web server using Excel
  •     In a Google Spreadsheet
  •     On the wall of your coffee room

Happy Scrumming!