The Backlog Process
| Step | Activity | Result | Comment |
|---|---|---|---|
| 1 | Board meet regularly to define and maintain corporate Roadmap. | Aspirational dates for releases and potential Themes for those releases. | Expectation is that this will be done bi-monthly or quarterly. |
| 2 | Product Owners in consultation with Business Analysts, Architects and Team Members break down the Themes into Stories (these may be Epics). | Stories in the Backlog | This is an ongoing activity of Product Owners and Business Analysts. Architectural input can be recognised in the form of acceptance criteria or notes to Software Engineers. |
| 3 | Product Owners, Business Analysts and Team Members assign relative complexity rating to User Stories in the Backlog | User Stories with complexity rating | Fibonacci sequence should be used for complexity values. 1, 2, 3, 5, 8, 13 are the only values to be used. Anything greater than 13 should be rated 99 and indicates that the Story needs significant further analysis and that the Story cannot be played. Ideally User Stories rated higher than 5 should not be issued to the Scrum team or accepted by them. |
| 4 | Product Owners, assisted by Business Analysts prioritise the User Stories in the light of current and predicted Velocity according to business need. | Prioritised User Stories | Ongoing activity of Product Owners. |
| 5 | Product Owners and Business Analysts meet on a daily basis to assign stories for the next two sprints and review any stories that have been found during the current sprints. | Stories assigned to sprints +1 and +2. New Stories added to the backlog. | The aim is to have a two sprints worth of work ready to be pushed to a scrum team. Stories can arrive at any time. They are reviewed by the Product Owners and Business Analysts who agree whether or not the Story should be added to the backlog. |
Daily Meeting Process
During the Agile lifecycle there will be stories being generated and broken down into smaller stories all the time. There needs to be a daily meeting of all parties interested in the scheduling of the backlog (mostly PO's) to discuss and agree the scheduling of these stories and also any new "release candidate" cards that have been generated outside the backlog. It is vital that the work being planned into upcoming yet unstarted sprints is still what is required most urgently.| Step | Activity | Result | Comment |
|---|---|---|---|
| 1 | User story cards are added to "release backlog" board(s) | Backlog items captured. | The release boards should hold all stories that are potentially to be delivered within the current release, some will be at epic level and others which are better understood will be at user story level. The boards should "flow" from left to right with the least defined and unscheduled (no sprint allocation) cards being to the left, then with sctions moving to the right to show iteration +2, iteration +1 and current iteration stories (effectively giving an idea as to the upcoming work for the next two sprints as well as detailing what is committed to at present. It is the job of the PO's to prioritise the work that goes from left to right. |
| 2 | Candidate cards are added as generated, to "release candidate" board. | Potential new backlog items captured. | The candidate board is usually located next to the backlog boards. Typically BA's and Testers will be creating and adding these cards as new functionality is uncovered, new defects are found, or extra complexity spawns from existing stories in play. |
| 3 | Daily Meeting #1 | Review Product Backlog for Feature Release | Daily meeting of all parties interested in the scheduling of the user story backlog (ideally first thing, circa 9.00am) to discuss and agree any re-scheduling of the existing backlog stories and any scheduling of new stories that have been added to the candidate board. Note: There may be a need to have a "Chief Product Owner" if parties can not agree easily who can arbitrate and have final say on schedule etc. |
| 4 | Daily Meeting #2 | Review Defect Backlog for Maintenance Release | Daily meeting of all parties interested in the scheduling of the bug story backlog (ideally straight after meeting #1 as participants may be the same) to discuss and agree any re-scheduling of the existing backlog stories and any scheduling of new stories that have been added to the candidate board. (This is all one backlog, just filtered to give clarity to users) |
No comments:
Post a Comment