Scrum

SCRUM is a way to organize the creation of software so that you can produce your end result of shipping high quality software that meets your “clients” expectations.

At a high level overview I really like scrum because it keeps your team cross-functional (instead of everyone retreating to their silos of familiarity) and because everyone on your team is working on the same project during the sprint it breeds a much better environment for collaboration.

Below is simply a list of my notes about the keywords and ideas that make up scrum.

SPRINTS

• Are usually 4 weeks but could be as little as 1 week.
• No new items can be added.
• At the end of the sprint you should have something that is tangible and will be truly “DONE”. The team reviews w/ stakeholders and demo’s application.
• Meet together as a team for 15 min every day

DONE

Done means that your software is integrated, fully tested, end-user documented, and potentially shippable. At the end of the sprint if your product isn’t shippable than you probably lack some automation or your team isn’t cross-functional enough.

SCRUM ROLES

• Product Owner - Maximizes ROI
• Team - is cross-functional and self-managing
  • There are no fixed specialist titles in a group
  • Multi-Learning
  • Team size is +/- 7 people
  • Team avoids multi-tasking across multiple projects
• Scrum Master - helps the product group learn and apply scrum

PRODUCT BACKLOG

A prioritized list of features and does not contain user stories.

• Detailed Appropriately - Top priorities are more fine-grain than lower priority items
• Estimated
• Emergent - The product backlog is regularly refined. Items may be added, removed, modified, split, and changed in priority.
• Prioritized - Most bang for your buck, tackle high risks early before the risks attack you.

SPRINT PLANNING

You have a meeting that is 1 hour long / week of sprint.

Sprint Planning Part 1:

• Review the high-priority items
• What and Why?
• Devise the Sprint Goal

Sprint Planning Part 2:

• How?
• Decide how much work will complete
• Sprint backlog
• Forecast

NOTE: Only volunteer for one task at a time.

DAILY SCRUM

• What has been accomplished since the last meeting?
• What will be done before the next meeting?
• What obstacles are in the way?

NOTE: This is for the benefit of the team and is not a status meeting to report to a manager.

TRACKING PROGRESS DURING THE SPRINT

• Update estimates in sprint backlog
• Sprint burndown chart
• How much work remains in the future

PRODUCT BACKLOG REFINEMENT

• Split big items
• Analyze Items
• Re-Estimate
• Re-Prioritize

TIP: Some % of each sprint should be dedicated by the whole team to refining the product backlog to support future sprints

SPRINT REVIEW

• Inspection and adaptation related to the product
• Only prepare 30 min

SPRINT RETROSPECTIVE

• Inspection and adaption related to the process and environment
• Timeboxed to 45 min / week of sprint

STARTING THE NEXT SPRINT

• Maintain a sustainable pace
• Everything is completely finished every sprint
• A “Release Sprint” is considered a necessary evil

MANAGING RELEASES

• Some releases are date driven
• Others require certain features to be built
• The Destination is more important than the journey

Summary

Basically scrum keeps your team from working on multiple projects at the same time, being segregated by defined rolls (which solves the John got it by a bus dilemma and we have no idea how to do what he does), keeps you from making software that isn’t tested or documented, and should help you achieve the end goal of shipping code that will be of a higher quality then if you didn’t use scrum.

Start by reading the Scrum Primer if you want to learn even more about scrum.