Divide your working area into four parts like this:
Agree on timebox
- It can be anything from one release to year or two
- Every time you place your Product Backlog Items on the template, you consider agreed timebox
Pull the elements from the backlog and place them on the template
- Must have = Requirements labeled as MUSTare critical in order for it to be successful. If even one of theMUST requirements is not included, the project should be considered a failure
- Should have = Requirements labeled as SHOULDare important but not necessary. While SHOULDrequirements can be as important as MUST, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back.
- Could have = Requirements labeled as COULDare desirable but not necessary, and could improve user experience or customer satisfaction at a low development cost. These will typically be included if time and resources permit.
- Won’thave = Requirements labeled as WON’T have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, WON’T requirements are not planned in the schedule.
- Verify items twice – especially from the „Must Have” template
- Usable for new PO for old products or an old PO for a new product
- You can make a session with your stakeholders
- It is difficult to connect this method to the KPI’s
- It might take a bit longer to discuss, but usually this discussion is OK
When to use this method
- When the backlog is bigger than the capacity of your team and you want to identify the crucial things
- When it’s difficult to understand what the core of your product is
- When the backlog needs to be roughly prioritized, set in order and planned for an entire release
- When your team isn’t sure how much it can do in the upcoming sprints and it needs directions from their PO about the required minimum that absolutely must be done
Are you ready to continue?
click here to go to next method – ROI