Scrum Made Clear

Certified Scrum trainer Kenneth S. Rubin has taught more than 18,000 people in more than 200 companies about the principles and methods of Scrum. He was the first managing director of the worldwide Scrum Alliance. His diagrams, tables and charts expertly illustrating every element of Scrum appear on almost every page of this hands-on manual. Rubin’s exhaustive, step-by-step description of Scrum will greatly assist leaders who are new to Agile and Scrum methodologies. These 400 pages about Scrum – including 22 pages of definitions – may be all any aspiring Scrum team member needs.

Multiple Scrum experts, solution architects, consultants and Agile coaches hail this as the crucial Scrum text. Given Scrum’s at times opaque nature and fundamental complexity, it seems the layperson could not go wrong by trusting these experts’ judgment and exploring Rubin’s vision of Scrum.

Product Development

Scrum emerged as a software development strategy in the mid-1980s. Rubin describes how it spread to all industries worldwide.

Waterfall and other traditional approaches to managing product development emphasize upfront planning to define an entire product. Rubin explains that this works for routine, predictable projects during which developers build out and test a product. The client receives something completed to its specifications, guidelines the developers might have written months earlier. 

Plan-driven development works well if you are applying it to problems that are well-defined, predictable and unlikely to undergo any significant change. Kenneth S. Rubin

Scrum acknowledges that due to variability and uncertainty, no one knows enough upfront to create an end-to-end plan. 

Ongoing Planning 

Scrum calls for seeing what works, step by step, confirming that it meets customer needs and adjusting accordingly – in real time. It calls for building, testing and gathering feedback about deployable components or features of an overall product or service. 

An old myth states that development with Scrum takes off with no planning. We just start the first Sprint and figure out the details in flight. This isn’t true.Kenneth S. Rubin

Rubin emphasizes that Scrum allows for learning, discovery, inspiration and creativity. With Scrum, no one knows at the time of launch what the final product will look like. Instead, leaders and product owners work with teams and stakeholders to plan product developments and releases as warranted. Scrum gains efficiency by not defining precise requirements for development since they will change over time.

Retain Flexibility

One lesson from Scrum is to keep your product backlog flexible. Some products’ potential value may diminish or disappear. And, new products might emerge at the top of the priority backlog or displace some already started.

Rubin notes Scrum’s inventors’ counterintuitive genius: To retain flexibility, they did not create a detailed methodology, so, he counsels, don’t expect to get Scrum right on your first try. Invest time and practice to find the version that fits your approach.

Scrum Teams

Product owners act as combination project and product managers, creating a bridge for the team, customers and other stakeholders. Product owners represent the stakeholders, and have authority over prioritizing the major components in the product backlog inventory (PBI). This means, Rubin clarifies, they can insert new items, change priorities and eliminate items that no longer add value.

The product backlog is a prioritized list of desired product functionality. It provides a centralized and shared understanding of what to build and the order in which to build it.Kenneth S. Rubin

ScrumMasters keep the work visible, permitting meaningful progress assessments and enabling rapid adjustments.

Scrum development team members need expertise in their own domains – testing, coding and the like – as well as an understanding of the product’s requirements and business value. The team helps plan the Sprint’s work, builds the product and assures its functionality.

Iterative Sprints

Sprints help organizations and teams break complex product development into manageable work chunks. Short consistent Sprints permit faster feedback as they enable more deliverables for clients and quicker accomplishments for teams, thus motivating and engaging everyone. Sprints, Rubin asserts, must end on time. If a Sprint proves unproductive, he advises, start another one.

Each Sprint is focused on completing an item from the PBI. The product manager details the product backlog with the team and customer, balancing the costs of delay with the value of each feature. Each Sprint is its own brief project and should address the next highest priority element or feature in the PBI, moving the team closer to completing features and products.

“INVEST”

Stories describe project or product development from the customers’ perspective – why they want the product and how it will help them.

In Scrum, it’s not about how much work we start; it’s all about what customer-valuable work we finish.Kenneth S. Rubin

Rubin proposes the “INVEST” test to determine a story’s worthiness as a Sprint guide. Each story should be Independent – stand-alone; Negotiable – flexible and adjustable; Valuable – it delivers what the customer wants; Estimable – size, cost and time required; Small – break it into more stories; and Testable – measurable.

Development teams should sort out detailed feature stories in the PBI by estimating their comparable sizes – extra-small, small, medium, large or extra-large – relative to their complexity.

At the end of a Sprint, agree on whether the team completed its tasks and demonstrated the resulting features. Ask for feedback and gather ideas, insights, and any requests for changes or new features.

Sprint retrospectives give the whole Scrum team an opportunity to stop bumping along for a moment and think.Kenneth S. Rubin

Rubin recommends conducting a Sprint retrospective with the product owner, ScrumMaster and development team to air constructive criticism, concerns and ideas.

Elegance

Rubin’s breakdown of Scrum is essentially elegant and almost astonishingly comprehensible. Because he avoids jargon and uses simple, evocative sentences, complete beginners should be able to generate, run, complete and evaluate a Scrum process simply by following Rubin’s guidance page by page, and – in keeping with Scrum methodology – never turning to the next page until you fully understand the one in front of you. His inclusion of drawings, diagrams and graphics proves helpful and clarifying. Beginners will study those often; more experienced implementers, a bit less so. Grateful readers will thank Rubin for communicating his multi-leveled understanding with such clarity.

Other guides to Scrum include Scrum by Jeff and J.J. Sutherland and Scrum for Dummies by Mark C. Layton.