With its scrums, sprints and stories, Scrum Management always sounds intriguing. I’ve been involved with several teams who have either used this system knowingly, or have employed elements from it. However, I’ve never seen the process formalised until I spotted it in the January 2015 edition of Wired magazine (where they had compressed a version of Jeff Sutherland’s book). Wikipedia tells me that this style of software development emerged in 1986 – so I guess I’ve been slow in investigating the approach.

Wired describes it as a seven-step process:

1. Small  teams. These should include the product owner, who has the vision and decides on the order in which things should be done, and the scrum master who facilitates communication and removes obstacles.

2. Tell stories. Each new features should be associated with a short story about the user and why the feature will add value for the user.

3. Assign effort points. Compare the stories and give them points for effort involved (or T-shirt sizes: small, medium, large and extra large).

4. Prioritise features. Each sprint should end with something that can be demoed, so make the chunks of work small enough to fit into a sprint.

5. Sprint. A sprint should be 1-4 weeks long – long enough to deal with a set amount of effort points.

6. Scrum. A 15-minute meeting every morning, standing up, so you’re not tempted to settle in. Three questions. What did you do yesterday to help finish the sprint? What will you do today to help finish the sprint? What obstacles need to be overcome?

7. Sprint review. At the end of the sprint the team meets to discuss what has been achieved, and to improve working practices for the next sprint.