Scrum, Scrum, Scrum. We’ve been covering Scrum in such detail it makes you sick. And now we’ve finally covered it all (the basics, that is). I’m still quite sure we’ll be returning with more rationale, elaborations and goobledygook in general.
This will to some degree be a copy of the Scrum basics-post which ran July 16th, but now with added links, an image and some further reading.
The Basics Once More (Only With Links This Time)
2. Hold a monthly sprint planning meeting. Select the top requirements from the product backlog during Sprint Planning, part 1. The team break these requirements into actionable items (tasks), during the second segment, and carefully adds their time estimates. A goal that the team can commit to is then constructed for the sprint. Everything put into the sprint should be potentially ready for production before the sprint ends, remember? Tools to aid you adding the correct amount of requirements to the sprint is the calculated sprint velocity (how many ideal man-hours you can put into the sprint) versus the task estimates. Sprint velocity, in turn, depends on the focus factor. More on these new terms later.
3. Do The Sprint (with Daily Scrums). The team carries out the sprint during the coming month, and Scrum Masters are mere facilitators at this stage. The team self-organizes to make the real magic happen. Through daily scrums (short, informal team get-togethers) lasting only 5 to 15 minutes regardless of team size, the team stays synchronized and focused on the sprint tasks. Every team member answer only three questions; a) What did I do since our last daily scrum? b) What am I planning to do until the next daily scrum? c) What is stopping me from working as effectively as possible, if anything?
4. Sprint review. AKA The Demo. The team explains the goal of the sprint, and shows off the requirements that has been turned in to finished functionality, potentially ready for production, in a demo. Anyone can turn up to this event, and the demo should be understandable by the customer. Feedback is gathered during and after the review.
5. Sprint retrospect. The goal is to learn something from the just finished sprint. The team discuss the following three questions : a) What went well? b) What can be improved? and c) What will we focus on improving during the next sprint? Suggestions for improvement can be turned into requirements and put into the product backlog, ensuring that the team commits to them during upcoming sprints.
6. Rinse and repeat every 30 days.And that’s all there is to it.
We have now, finally, visited each of these topics in more detail, and thus we’ve covered all Scrum basics, including rationale and some elaboration. Stay tuned with RSS for future discussions on how we do Scrum in details, how we experience the benefits, and demonstrations on the tools we are building to support our process, including Scrum.
The Timeline Overview
While there exist excellent visual representations of the Scrum process (one more right here). I have yet to see one that visualize how small the overhead of the Scrum framework really is. It’s certainly always around working its little magic, like that professional waiter who always notice when your glass is half empty and appears from nowhere to fill it for you, but just as that waiter will make an effort not to disturb you, Scrum will never deprive you of more “real work” hours than absolutely necessary.
This timeline overview shows you how there is a small setup time of 8 hours (after creating the initial product backlog / requirements specification, which is not time-boxed), and then there’s the great red body of “real work”, before rounding things off with demo and retrospect. Smooth, simple and effective.
There are several excellent sources for more reading on Scrum. I’ll list a few that I have found useful.
- Scrum From the Trenches – Henrik Kniberg (Infoq)
I list this first, not because I think it is the greatest resource, but because I found it an honest and amusing introductory story to Scrum. Infoq’s tools and techniques for implementing Scrum seem far from flawless, and it’s not exactly a Mark Twain story as to what language is concerned. Still it is open and forthright and down to earth about Scrum. Very useful when you find yourself in a similar situation, wanting to understand what Scrum really does to your process.
- Agile Project Management With Scrum – by Ken Schwaber
This book is great for those who like to learn by reading real-life stories. The Scrum framework is described in just a few pages at the start, and elaborated further with a few more pages at the end. The rest is real-life stories from Mr. Schwaber’s career. Some of them are entertaining, most of them are useful for grasping the Scrum-concept. If you manage to disregard the fact that most of the book is really just marketing of Schwaber’s own skills, you’ll even enjoy it very much. It’s very educational.
- Mountain Goat Software on Scrum
While it can be compared with a giant perfectly roasted steak as far as facts on Scrum is concerned, reading it can be compared to being forced eating the goddamn beautiful steak with no sauce, no potatoes, no spice, no nothing. And then you barely want to eat it anymore. I have sometimes used Mountain Goat’s description of Scrum as a reference on single topics — as an ingredient in other bigger recipes, so to speak — but be careful to use it as your main course. You might choke on it.
This post is being edited and maintained over time. Thus, this post is more of a bliki-format than a pure blog-post.