Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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.
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 put 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.
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:
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.
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.
