At one of our Program Management meetings, I was asked what was absolutely necessary to do for Scrum and Sprints. I was very reticent to write up a check-list of what is needed as it will always have a prescribed, controlling feel to enforce how to work. Using a cheat-sheet like this can leave short that full understanding, of being able to grok Agile. There is so much more to it, and so very much that has been left out, or could be misinterpreted. Yet I wound up writing it. Our group is so distributed and the team was asking for this to help them. I wrote up a draft, reviewed with the team and refined, and wound up with the following:

• Recipe for Scrum Basics
  • Before Sprinting you need:
  • To begin a sprint you need:
  • While in a sprint:
  • After a sprint:
  • Caveats:
  • What to do when trend lines go flat:
  • Visual information radiators:
• Necessary team size
• Team additions to ensure bar is met
  • Video Hub

Recipe for Scrum Basics

All of this work is required before a team is considered to be in a Scrum and Sprinting.

Before Sprinting you need:

1. Forced-ranked backlog of features
2. Backlog sized for release plan
3. Automated builds
4. Regression testing
5. End-to-end environment
   1. dev
   2. stage
   3. test
   4. CI
6. Agreement from team on sustainable working hours
   1. Between 4-6 hours a day
   2. Heads-down, uninterrupted work hours
   3. What is not included in sustaining hours
      1. All meetings
      2. Reading email or other documents
      3. Other breaks

To begin a sprint you need:

1. Enough features sized for more than one sprint
2. Enough items on backlog force-ranked for more than one sprint
3. Product Owner states goal of sprint
4. Current estimate of team velocity for calculating sprint capacity
   1. Story points finished per sprint
   2. When there is no historical data, use the first planned sprint. Combine that with just finished sprints until enough history for more accurate trends.
5. Acceptance criteria written by Prod Mgr for each feature taken in to sprint
6. Capacity in hours of the team for the sprint
   1. sustainable hours multiplied by days in sprint per person
   2. subtract out time for looking ahead to the next sprint, operations, production and other support
7. Break down one backlog item
   1. Product Manger answers any domain questions about item
   2. Product manager lists out all acceptance criteria if missing
   3. All tasks listed by team to get a backlog item to DONE and DEPLOYED
   4. Subtract hours of tasks from capacity
   5. Ask team if they have capacity to plan out next backlog item, if yes carry on and if no, stop

While in a sprint:

1. Team works on highest priority backlog items FIRST
2. Add up story points finished and track on a big visible chart
3. Track hourly burn down
4. Update WIP tasks with hours remaining
5. Have a daily stand up for no more that 15 minutes, which starts ON TIME
   1. Required participants
      • Entire team responsible for tasks in the sprint
      • Product Owner
      • Scrum Master
      • Other Core Team Members
   2. Record impediments risen
   3. Have task board in synch with where team really is at
6. After stand up
   1. Update tasks
   2. Prioritize impediments
   3. print out new burn down charts, or plot new point if chart is hand-drawn
      1. hourly burn down
      2. point take off
      3. open vs closed defect rate
7. Any finished backlog items for the day are verified with Product Owner against acceptance criteria

NOTE: Attempt to resolve all impediments in the day they are raised.

After a sprint:

1. Find average of best 3, average of worst 3 and last sprint story point totals
   1. If less than 3 sprints, use average of all and last sprint
2. Calculate trends for release
3. Review finished features now on staging from sprint
4. Retrospect on sprint process
5. Record if sprint was a success
   1. Sprint goal met
   2. All tasks created in Sprint planning are completed
   3. Success also means at least one demo-able feature on staging from sprint
   4. Success/fail determined in retrospective by team
6. Plan next sprint!

Caveats:

1. Story points are only added when a feature is DONE
   1. Meets acceptance criteria
   2. In staging
   3. Test plans executed and all features regressed without error
2. Review only finished features
3. Sprints can be aborted
   1. Know that goal will not be met
   2. Complete change in direction from previous goal
   3. Defects and other blocks to reaching goal have overwhelmed team
4. Decisions are made at the lowest responsible level
   1. Teams self organize to create and accomplish tasks for backlog items
   2. Core team strives to remove impediments to team completing tasks
5. Break down backlog items to tasks of 2-4 hours in length, with no task more than 1.5 days
6. Inestimable backlog items are the only candidates for spikes
7. Spikes are time-boxed at one calendar day (respike next Sprint or have list of new estimable backlog items)
8. The team can choose to skip backlog items
   1. Unclear and vague items
   2. Some part of technology not available for effective development
   3. Any other valid justifications from the team

What to do when trend lines go flat:

1. Do not worry about it until 10-20% in to the sprint
2. Remove lowest rank, and not started work from Sprint and put back to Product Backlog
3. Remove work which does not support Sprint goal

Visual information radiators:

1. Sprint board to show task/feature progress
2. Weekly story point take-off
3. Daily task burn down
4. Cumulative work item flow

Necessary team size

• 7 developers, +/ 2
  • Mix of all roles needed, some suggestions
    • DEV (FE/BE)
    • QA and Automation
    • Configuration and release management
    • UED/IAD
    • OPS and DBA
• 1 Product Owner
  • Represents customer and market needs
  • Answers domain questions for development team
• 1 Scrum Master
  • Protects the team from ANY interruptions
  • Facilitates communication and conflict
• Core Team
  • Product Owner (aka Product Manager)
  • Engineering Manager
  • Architect
  • QA Manager
  • Program Manager
  • Scrum Master (aka Project Manager)