Publish Release Plan

Edit Subject

Can I give 10 votes for this one?
Our product owner has to deal with multiple release plans of project managers at different customer projects for the same product.
This would be of enormous help

Can we do this at both the product and program levels?

I like the idea, but worry that something might get missed.

I'm currently theming items as 'done' or 'sprint' and creating a PBI web report to show just those items.

I'm not sure about the 'fallen off' part, since those items will still be around on the backlog, but just pushed to another release, meaning that they are findable.

I'll second this idea - this would definitely be beneficial to use with multiple stakeholders and projects with two products and one program. We would definitely benefit from program level support for this as well. Right now we're using the PBI Web Report for this which is far from ideal

I previously marked this idea as one that I like, and I still do. I wanted to stress, though that I have to agree that having this at the program / epic level would be most beneficial. We are moving towards having our high-level release objectives be the epics within a program release allowing us to use the roll-up status reporting to guage the progress towards each objective.

Right now we are accomplishing this by having the Product Owners (BSAs) subjectively apply emoticons to each objective at the end of each sprint.

Perhaps you all could help me focus this a bit more.

The original poster talks about "roadmaps" in the sense of PBIs in Sprints. Isn't something like that available today with the PBI module in web reports? I'm not following what's missing from that report that would justify building a new report.

I do understand the follow-on requests focusing around the Epic (Product and Program) level.

Would this essentially be a listing of Epics associated to releases? Would you want to see PBIs in this report as well?

Could someone provide some more detail/focus to help me understand the essence of this request?

Thanks!
Victor Szalvay
ScrumWorks Pro Product Owner

What we would like is a Web report based on the Release Planner view, which lists Epics associated with a Release, the Descriptions and the Effort budgeted.

Thanks

This topic seems to have elicited different pictures in people's heads.

I agree that Web Reports for the programs would be useful.

The Epic Progress Report seems to meet some of the needs (list of epics associated with the release and their points done, in progress, remaining).

However,
1) What about backlog items that may still not have points? Are you putting an asterisk on those epics to reflect that?
2) A (web) report of all backlog items for selected epic(s) by product (team) with a filter by status would be useful when having to renegotiate objectives due to unanticipated work / difficulties.

Being able to have program / epic level reporting with drill down to products would probably also be helpful.

Thanks!

I think there's 2 ideas here in the follow on posts:

One is to publish/web report the 'release planner' at both the program and product level. Better yet, the program level can be drilled down into a particular product level release planner. Simplest method is to just publish what is at the program level for viewing, but with some filtering.

2ndly, there is the 'can we complete the objectives in time' discussion.

The release forecast chart, Sprint change chart and the PBI module all basically cover this, but not totally. What seems to be being asked for is a merger, of sorts, of the key pieces from those 3 reports to determine what specific stories may or may not be completed by the end of the next release, based upon velocity (configurable) and the change reports per sprint (what got added during a sprint which forced something else out, etc). I guess a configuration for number of sprints forecast would be needed to determine the cutoff line.

This second report would minimize the need to view 3 different reports and then manually calculate which stories will 'make it' and which ones are clearly out of scope for the release, given the velocity.

User example:

We're headed into release 2 (of at least 3) for our product. Based upon business needs, we have no more than 4 sprints before having to go to production. Checking the Release burndown chart, it shows that we have 6+ sprints left of effort, given the teams current velocity.

The product owner has Epic priorities done. At the program level, we have 5 epics in the release, each at differing effort levels to complete. Within the product level, the backlog has been 'prioritized', but we still have plenty of 'epic stories' to breakdown to proper sizes within the release time frame.

At some point in here, the product owner can, after doing manual calculations, tag the stories/PBIs until a 4 x velocity effort number is achieved, and create a PBI based web report. That report may be useful on the first day of the sprint, but once the team starts sprinting, it's out of date. So it has to be manually updated. It also doesn't show that in sprint 2, we removed 4 stories from the sprint in favour of fixing some critical bugs that appeared after going to production. Nor the fact that we broke down 3 'epic stories' and decided only parts of those epics had direct ROI and the rest needed more business input before being scheduled. Somewhere in sprint 3 three members got sick, so the team couldn't complete all stories as negotiated.

Now we're in sprint 4 and the Original report sold to business for the release plan is no longer useful. We may still be completing 4 x original velocity, but the actual stories being completed are different that the original ones. At this point the product owner needs to pick the final stories to get into the release with the business expecting 'everything'.

Not sure how clear the above is, but that's basically a good reason to have the 2nd report.