Thursday, October 29, 2009

An Outline for Scrum

I recently created a Scrum outline that some may find helpful. Enjoy:

Listed below is an outline for Scrum. This is meant to be used as a guide, the Scrum team is free to adjust and implement based upon team needs. The guiding ideas of the Agile Manifesto and 12 Agile principles should be followed when creating specifics for the Scrum team. Note that you can download the word version of this document here.

  1. Roles
    1. Scrum Team
      1. Performs the work
      2. Creates their own tasks
      3. Pulls stories from the Product Backlog
      4. Owns the sprint backlog
      5. Provides estimates and commitments
    2. Product Owner
      1. Accountable for the product
      2. Owns the Product Backlog
      3. Prioritizes the Product Backlog
      4. Provides goals and vision
      5. Product Owner determines when to release
    3. Scrum Master
      1. Enforces process
      2. Prevents and remove impediments
      3. Tracks metrics
      4. Facilitates Daily Scrum


     

  2. Scrum Board
    1. Sections for:
      1. Work waiting to be picked up
      2. Work in progress
      3. Work ready for review
      4. Work that is DONE
    2. Sprint burn down chart
    3. Project burn down chart
    4. List of impediments
    5. High visible in a public area
    6. Daily Scrum revolves around Scrum board
    7. Team interacts with Scrum board during Daily Scrum


     

  3. Product
    1. Product Backlog
      1. List of all features/PBI/user stories for the product
      2. Can also contain bugs, technical pieces, and spikes
      3. Owned, maintained and prioritized by the product owner, thought team members can add items to the Product Backlog
    2. Sprint Backlog
      1. Prioritized list of features the team is developing during the iteration
      2. Sprint Backlog created by the team
        1. Items in Sprint Backlog pulled based on priority from the Product Backlog
        2. Represents the work that the team has committed to complete for the Sprint
    3. Roadmap
      1. Mapping of all Product Backlog item to a "timeline". This can be done by month, sprint, release, quarter, etc
      2. Product Owner provides the Roadmap content and prioritization, the Team provides the estimation
    4. Release
      1. Product Owner determines release
      2. A regular recurring release cycle is recommended


     

  4. Meetings
    1. Daily Scrum
      1. 15 minutes max
      2. Each team member states:
        1. What I did since last Daily Scrum
        2. What I plan on doing today
        3. My impediments
        4. My work that needs to be reviewed
    2. Sprint Backlog Planning
      1. Product owner presents top priority items from the Product Backlog that are candidates for the upcoming Sprint
      2. Team uses planning poker to estimate each user story/item
      3. Stories that cannot be estimated upon can be converted to Spikes
      4. Team commits to a set of user stories/items for the Sprint
      5. Stories are either rank ordered or marked as high, medium, low (and optionally stretch) priority
      6. These items become the Sprint backlog
    3. Sprint Task Planning
      1. The team reviews each story and decomposes it into tasks
      2. Hours (Optional)
        1. Team provides estimated hours for tasks (optional)
        2. Team capacity should be # of available hours (should be a number less than 8 per resource, something between 4~6) and number of resources
        3. Take into account holidays, hours, and misc outages
        4. Take into account unplanned work
      3. Generally, work is pulled real time and not assigned during task planning
    4. Sprint Closeout / Review
      1. The team along, with the PO and Scrum Master, review the user stories/tasks/spikes
      2. Ensure each is done, a story is either done or not done
      3. Story done-ness is defined by the story acceptance criteria, not all tasks for a story need be completed for the story to be done
      4. Collect total story points completed (optionally actual hours as well)
      5. Note actual velocity and completion percentage
    5. Sprint Retrospectives
      1. Team reviews the process and discusses the things that have been working well and potential areas of improvement
      2. The Scrum Master and Scrum Team create and update the process norms for the team
    6. Meetings Techniques
      1. Meetings should have a clearly stated goal or desired result
      2. Meetings should be timeboxed
      3. A parking lot can be used to hold ideas that or of note, but not directly related to the meeting goals or desired outcomes


     

  5. Estimation & Metrics
    1. Epics - a high level idea or theme that is comprised of user stories.
    2. User Stories
      1. Features that the team can estimated and decomposed into tasks
      2. Ideally in the form of "As a {user}, I want {feature} so that {value}."
      3. Each story has an acceptance criteria so that we know when the story is done
    3. Tasks
      1. Team decomposes user stories are decomposed into tasks
      2. Tasks are not assigned, rather they are pulled real time
      3. Team can provide hours estimates at the task level (optional)
    4. Spikes
      1. An allocation of time the team uses to investigate unknowns, research potential solutions, or addresses issues that are not stories or bugs
      2. A spike should have a goal
      3. At the end of the timebox, the team should be closer to addressing the goal of the spike
    5. Planning Poker
      1. Each team member provides estimates for user stories based upon a modified Fibonacci series
      2. As long as the team members are close in estimates, the team can proceed to the next user story
      3. If there is an inability to provide estimates or estimates differ by several orders of magnitude, then further discussions should occur for the story
    6. Story Points
      1. Story points are measure of the complexity of a story relative to previous stories
      2. This factors in both the amount of time it takes for the story and the difficulty of the story
    7. Velocity
      1. Planned velocity is the total number of story points that the team has committed for the iteration
      2. Actual velocity is the total number of story points that the team completed for the iteration
      3. Percentage completion is the actual velocity divided by the planned velocity
    8. Unplanned work – Unplanned work should be tracked. This can later be referenced in process improvement discussions.


     

  6. Engineering
    1. Continuous Integration    - Critical for the rapid pace of Agile development
    2. Automated testing – automate testing as much as possible to help build quality into the process


     

3 comments:

  1. Hi Richard,

    Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time and de-focused our colleagues). Because of this we developed a SaaS tool to "automate" the daily standup meetings - with just a single email. If you like to take a look: www.30secondsmail.com.

    Best,

    Ajie

    ReplyDelete
  2. Agile Transformation enablement program is an approach in which organization move towards the gain the foundation soft skills needed in a highly collaborative and high performing culture. So learn how to execute transformation enablement program and lead our own transformation internally.

    ReplyDelete