1

Using Confluence I put together a series of PRDs for a future release. Each PRD describes a functional 'unit' of the application, such as 'editor', 'user management', 'customer management', etc. Using the built-in Product Requirements Document, I set the Target Release (e.g. "v1") for each PRD. Following the MoSCoW method I then set the Importance for each Requirement. All of this follows pretty closely the very helpful guide provided by Confluence Support.

The problem then becomes, how does one set a list of requirements for the next release (e.g. "v2")?

If the PRD descibes a functional unit, it will invariably contain requirements for different releases (it won't be 'done' when that version ships), so it's odd that there's a Target Release for the entire PRD. It seems like it would make more sense to target versions for each requirement in the PRD, which the MoSCow method emulates in a way, but it's not the same thing.

  1. One way to address this might be to have a different PRD for each funtional unit + version, such as 'editor v1' and 'editor v2'. The problem here is that there's likely duplication of requirements: something with is "could have" for v1 might be "should have" for v2 and "must have" for v3. This feels messy. Also, it seems to run counter to the notion of a Target Release for the PRD. The Confluence Support guide linked to above has a PRD called "Android App v1 Requirements" with a Target Release of... wait for it... "1.0". This seems at best redundant and at worst confusing.

  2. Another way to address this might be to leave the PRDs the way they are, and when the version is released, update the Target Release and the Importance for each of the remaining Requirements for each PRD. So, once v1 is out the door, change the 'editor' Target Release to "v2", remove the requirements that shipped and bump up the Importance of the requirements that are still there. The problem here is that visibility is limited to the next release. Perhaps this is fine, but if you're doing any sort of Roadmap it might be nice to offer guidance around requirements for a number of different versions comming down the pipe.

  3. Yet a third option might be to have separate documents for each version and list the requirements for each, perhaps even linking back to the PRDs. So there could be a "v1 requirements" page with a 'editor' section that lists all the "must haves" for this release, and then a "v2 requirements" page, etc. The problem here is that this seems like a lot of duplication which could potentially become messy. Not only do you have to keep track of each requirements on the PRD, but you have to have track them all on each version requirements page.

This seems like there should be a straight-forward way to do this, but I've looked off and on for weeks and can't seem to find anything that outlines a procedure for handling this sort of thing while using Confluence's Product Requirements Docs. I like my third option the best because it seems most consistent with the tools provided by Confluence, but I'd like to hear other opinions.

Improve this question

2 Answers 2

Reset to default
1

Context: I am working on an online product (website) with a rather fast release cycle (minor releases every month, major releases every 6-9 months)

My practice:

  • create the original PRD containing the requirements, prioritised using MoSCoW, and with links to Jira epics & stories
  • at a certain time/milestone (usually whenever we start planning a new major version), that page gets renamed to v1 and a copy is created, v2.
  • the v1 version is moved to be a child of the v2 version (kept for historical purposes)
  • going forward I clean up v2 (removing what is already completed/scheduled for v1), add new stories and reprioritise

I like keeping stories in 1 PRD (even if they are Cs or Ws) so that people would get the big picture when reading the PRD (and not just focus on the current version's goals).

Ms are a must for that release. Cs are a stretch.

I try not to do release planning in Confluence for anything less than a major version (minor version release planning is done in Jira) - and based on my experience 1 major version planning is good enough (you actually don't know what the next 6 months will bring but your PRD should capture the future in the Cs and Ws).

Improve this answer
2
  • Clever idea. Thanks. That still makes the "target release" field somewhat redundant with the title of the page, but I'll give this some thought.
    – Mark Cramer
    Commented Jun 22, 2018 at 6:47
  • I'm implementing this now and it works well. One hint: if you make the 'old' version a child of the 'new' version, it'll appear in the PRD summary. To resolve this I moved the old version to a page outside of the main PRD tree and then edited the Page Properties Report macro to only include PRDs with a particular parent. I hope that helps.
    – Mark Cramer
    Commented Jan 24, 2019 at 23:07
0

A clever and relatively simple 'workaround' was suggested to me by a colleague. If the Target Release for a PRD is, for example, v1 and yet there are intermediate milestones (e.g. alpha, beta) then multiple status macros may be used in the Importance column to reflect the priorities of different requirements at each milestone.

The image below should make things clear quickly, but unless otherwise specified, the Importance is for the Target Release. Should the Importance vary for the intermediate milestones, this can be indicated with additional status macros.

Importance column in Confluence PRD

Once the Target Release is achieved, or planning begins on a subsequent release, I like the idea proposed by https://pm.stackexchange.com/a/24301/29755 to create a copy of the PRD to move to the child position before updating all the information on the original.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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