In the third phase of the team project, you will use the characteristics of your project and estimates for the user stories created in Phase 2 to create a product backlog and a release plan.

Ordinarily, as explained in the agile estimation course content, product teams might use group-based estimation processes to arrive at estimates of difficulty for user stories. In light of the fact that this course is asynchronous, group-based estimation will not be required. However, team members are expected to create plausible estimates of difficulty of the features embodied in the user stories you created in Phase 2. Each team may decide how to allocate responsibility for that. As the result of this process, teams might decide to decompose a large story (an epic) into multiple stories. Teams do need to agree upon a scale to use for estimation, whether it be some variation of the Fibonacci sequence described in course content, or some other scale such as the T-shirt size scale.

Product Backlog / Release Plan

The next step is to take the collection of user stories with estimates made by your team, and use them to create a product backlog for your hypothetical product. Remember, the product backlog is a prioritized list of all of the features which may be included in your product. You can express it in the form of a Word table or an Excel spreadsheet. The table should contain the user story describing the feature, the agreed-upon priority of that story as well as the agreed-upon estimate of the degree of difficulty of the story itself. Stories should be shown in the backlog in order of priority, with the highest priority stories at the top and lowest at the bottom.

Your team is allowed to select any prioritization scheme it prefers. It could be high, medium low, a numerical scale, the scale based on the MoSCoW mnemonic (must have, should have, could have and would be nice to have), or one that you devise yourselves. Be sure to describe the scale in your submission.

Your team must also develop a product release plan. This doesn’t have to be anything more complicated than listing a set of phases and grouping your user stories into each phase. It’s acceptable to consider each sprint to be a phase, but you may decide to set up your phases so that they are comprised of multiple sprints. Remember that features allocated to the last phases of a project may not be completed, so it may not be necessary to have the stories representing them be decomposed with relatively small effort estimates.

Keep in mind you will not be expected to actually create your product. The point of this exercise is to consider how to prioritize stories into a backlog and a release plan. Unless the prioritization indicates something which seems impossible (such as indicating a wall would be painted before it is built), your backlog will not be challenged.