1

I've been asked to create a "plan on a page" to give to Senior Management for an agile project, and I am struggling with how to reconcile two very different ways of working.

They are looking for when certain aspects of the project will be delivered, including nice-to-haves, and I am trying to explain that since it is iterative, there is no fixed plan of delivery and some/many of the nice-to-haves will change and be adjusted as part of the iterations.

5

This is one of the difficulties with running an agile project in an organization where management is not yet completely comfortable with it.

Remember the sacred triangle (Resources, Time and Results/Scope). You are being asked, given a set of resources, when (time) will you have a given result (scope) accomplished. However, using an agile methodology, you likely do not even have the stories all sized, yet.

If you have a fixed schedule and fixed resources, all you have left to vary is scope. So, I would suggest that you look at key points in time (perhaps 1/4, 1/2, 1/3 and completely through the project) and for each point create two lines, one very conservative, the other aggressive, showing a range of what you expect could be accomplished by that point. You will have to come up with some spitball estimate for story sizes.

The important point is, do not infer greater precision to your estimate than your knowledge allows, and emphasize that this is a broad plan for an agile project, which means that it will change.

2

At the very least, you should be able to show the start and end dates of each sprint, including the key deliverables of the current sprint plus any working assumptions as to what will be in the next sprint. If there are any hard target dates (which I appreciate should not be there, but we all know that is not always reality), then show them as milestones on your plan-on-a-page. If you won't actually release a new version at the end of the current sprint, try to indicate any anticipated release dates too.

I find that a plan-on-a-page can be a powerful way to explain to senior stakeholders how the project is progressing, even if it is not 100% accurate. I'm not suggesting for a moment that you should deliberately misrepresent the truth, but you can out whatever you like in such a document, and if used carefully, you will gain credibility and trust - which has to be a good thing. Remember, this is a communications tool, not a tool that you will necessarily use within the team or in scrums, so tailor your communications to your audience and recognise that they will not adhere strictly to the principles of your chosen methodology.

2

Agile Release Planning

In agile release planning, the unbound constraint is usually scope. So, an agile project generally has a fixed delivery cadence, fixed time-boxes, or a fixed number of iterations, but in general when to expect a piece of functionality to be delivered is only a forecast calculated from historical lead times rather than a fixed date.

There are certainly methods of delivering fixed-scope via agile, but they generally require treating schedule as the flexible constraint. This is probably the opposite of what you want.

One-Page Project Planning

If you're being asked to provide a one-page project plan, it's certainly possible to do that, although whether it's useful is debatable. I've bought (and personally disliked) the One-Page Project Manager agile template, which may meet your management's goal.

For myself, I found the template to be too "visually busy", and felt that it didn't really fit my conceptions of core Scrum and Kanban planning practices. In particular, the template and guidance seem very opinionated about release planning, estimation, prioritization, and the whole concept of done/not-done in ways that run counter to my own Scrum implementations. It also calculates burn-downs based on idealized hours and percentages, which is something I inherently dislike.

Despite my personal opinions about the template's suitability for my projects, it certainly seems like the concept (if not necessarily this specific implementation) would suite your needs well. You may even find that the template works well for you, even if it didn't work for me. It's definitely one of those "your mileage may vary" types of things.

1

Scrum release planning works well when it is targetted at the team's Product Owner.

The Product Owner works closely with the team and so they understand the assumptions that are made as a part of the planning. They are also the ones that get to make decisions about adding new stories and changing priorities. Hence they fundamentally understand that the plan can change.

Where release planning typically fails is when it is delivered to a senior management that are not fully engaged with the team. The classic 'plan on a page' starts out well intended, but often damages the Scrum process. This happens because:

  • Plans can become deadlines.
  • Once a plan is accepted it often results in a resistance to change. When changes are discussed there is a fear that they will impact on the plan and as a result change is avoided.
  • It is not unusual for senior management to misunderstand the implications of responding to change. Hence they will not interpret the plan in the way it is intended to be used.
  • People who are not fully engaged with the Scrum Team will often not understand the assumptions made as a part of planning. These assumptions may relate to technical approach, to requirements or to the people on the team (such as when holidays will happen, etc.).

My recommendation to you would be to work with your Product Owner to do release planning. Then ask the Product Owner to verbally communicate the release plan to senior management. Don't write things down.

The Product Owner should talk in terms of possible approaches and assumptions rather than in terms of definite dates. They should emphasise that they anticipate change and that this is likely to impact on timelines.

0

Maybe there is no fixed plan, but there is one plan to date and you should be able to represent it, because it's important to share the vision, not only with your management, but with anybody in the team needing a quick insight on the project

The goal could be to make it depending on your variables (e.g. current velocity compared to current backlog estimated) so that you can update it easily each time the strategy is changing.

  • I may not even go so far as to get velocity involved for something as high level as "plan on a page". I'd take the Epics/Milestones and do a Q1, Q2, etc. That keeps the fluctuation in stories and velocity out of the mix entirely. – RubberDuck Jul 29 '16 at 16:48
  • Yes it was an example to calculate macro planning based on your agile way of working. If you can't have it now maybe you will be able to use whatever type of estimation to draw a timeline with milestones – Julien Plée Jul 29 '16 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.