The Release Plan
Have it. Physically available. The physical Release Plan is the most important artifact a team can have. At first glance, you will say “This looks exactly like the Gantt Chart we already use in Microsoft Project.” Let me tell you that it’s not! It’s not even remotely the same because 1.) it’s physical and 2.) it’s a release plan, as in: you’re planning releases, not busy times. If you are doing your Scrum right, you’re talking about releasable product increments at the end of each sprint. Having the release plan physically available makes communication around it inevitable. More often than not, development teams wonder, what the overall roadmap looks like. Not only does a release plan next to the taskboard cater that need, it also makes communication about daily tasks much more valuable, as you can always challenge whether you’re working on the right stuff at the right time.
Get the stakeholders in front of that release plan as soon as possible and do it regularly! Try to have them add something to that plan, which is by nature limited in size, without having to take something else off the plan. They will fail. Either because it’s just too painful to take that one project they love so dearly off the plan and momentarily out of sight, or because they will get hit with a keyboard, held by a grim looking member of the development team.
This might strike you as common sense but since I have seen otherwise: put stories/epics onto your release plan ordered by priorities. It should be clear that whatever doesn’t get finished by the end of a sprint automatically moves to the top of the next sprint. Which might also mean that something else out of that sprint doesn’t make the cut. It really hurts not getting stuff done.
Also, include milestones at the top of your release plan. This will make it easier to verify current and future priorities.
Let me sum all of the above up again: put a physical release plan on the wall!