I was recently asked to put together a list of Scrum artifacts, so I figured that this would be a good topic for my latest blog entry. Some of this will just be a Scrum 101 refresher for those familiar with Scrum, but this may be useful for many.
A couple of notes:
· The list below represents a possible/typical implementation of Scrum. One does not have to follow these exact items to implement Scrum.
· Many of the items described below are implementation details of Scrum, but not specific artifacts prescribed by Scrum
In Ken Schwaber’s Agile Project Management with Scrum, the only items he has listed as Scrum Artifacts are the Product Backlog, the Sprint (Iteration) Backlog, and Increments of Potentially Shippable Product Functionality.
· And yes, I know, many items on my list are not really artifacts. To make things easier artifacts presented in black, general concepts in blue, and meetings in red.
Epics / User Stories / Tasks
User Stories – A feature that can be estimated.
Epic – A feature that cannot be reasonably estimated due to its complexity, scope or number of unknown issues.
Tasks – The work needed to complete a User Story.
Epics can usually be broken down into User Stories. User Stories can be broken down into Tasks.
Product Backlog – A list of the Epics and User Stories for the entire Project / Product. This list is prioritized by the Product Owner.
Sprint Backlog – A list of the Epics, User Stories, and Tasks that the team has committed to completing for the current iteration. This is created during the Iteration Planning Meeting.
Story Points – Units of estimation for User Stories. Usually based on a modified Fibonacci sequence.
Planning Poker – A method of estimation used in Iteration Planning. Each team member is given a set of card representing story points. For each user story, team members display a card representing their estimates. The team discusses the results and comes to a consensus on the estimation.
Iteration Planning Meeting – At the beginning of each iteration, the Scrum team meets to plan work for the iteration. The first part of the meeting involves the team working with the Product Owner in reviewing the prioritized Product Backlog and putting Story Points for each User Story. The team then commits to a certain number of User Stories for the iteration. The second portion of the iteration is typically used by the team to create a list of Tasks for each User Story in the iteration.
Project Board – This can be a physical board, a virtual board, or both. The board is usually placed in a visible location and presents the status of the iteration (and sometimes the entire project). The board usually contains an area for Work in Waiting, Work In Progress, Completed Work, and Verified Work. Other items that can be shown on the board include (but not limited to) a team calendar, burn down charts, and list of impediments.
Daily Scrum Meeting – A brief (15 minute) daily STAND UP meeting in which each team member gives a brief status up. This typically is limited to:
· What have I done since the last Scrum meeting.
· What I am planning to do today.
· List any blockers/impediments I have
· List any items I have ready for review
This meeting is typically held in front of the Project Board and the team members should update their tasks on the board during the meeting. Only team members should present during the meeting and all team members (barring physical considerations, such as a bad back or being very pregnant) should be standing the entire meeting. Standing meetings tend to not go very long.
Iteration Burn Down Chart – A graph displaying the amount of work completed and amount of work remaining for an iteration.
Project Burn Down Chart – A graph displaying work completed and work remaining in the project.
Team Velocity – The amount of story points a team has completed or can complete in an iteration.
Iteration Review Meeting – Held at the end of an iteration, the Iteration Review allows the Product Owner, and potentially stakeholders and other interested parties, to review the deliverables for the iteration. All deliverables should be fully tested, defect free, ready to ship increments of functionality.
Team Retrospective Meeting – Held at the end of an iteration, the retrospective meeting typically allows the team members to discuss what has been working well, what has not been working well, and discuss any ideas for improvements or changes to the process.
Back From The Dead - BlogEngine.NET
1 year ago