It can be important to read game instructions and understand how a game is played to fully enjoy the playing experience. It certainly is for… Scrum. Here are our game instructions that can help you judge whether it is a game suitable for you.
The goal of the game is to optimize and control the delivery of Valuable Software in turbulent enterprise, business and market circumstances. Control is achieved via frequent Inspect & Adapt cycles and the ability of the players to learn and improve, to become better players. Actively collaborating with real business players is a major help in achieving the goal of Business Agility, and increased competitiveness and market position.
You will find that it requires great discipline, but leaves much room for personal creativity. You will find that it is based upon respect for the people-players through a subtle and balanced separation of responsibilities. And you will find that fully respecting the rules of the game, not taking shortcuts on rules and roles or short-circuiting the empirical grounds of the game, will deliver you the most joys and highest benefits.
But that level is best obtained by starting the game and going through its self-learning evolutions. GO!
On a Scrum Team, Business is present as the Product Owner, a one-person player role. The Product Owner represents all stakeholders to the Team (of Developers), a multi-person player role. Despite the various strategic product management tasks outside of the Scrum Team, it is important that the Product Owner actively engages with the Team (of Developers). The Product Owner is expected to structure the business expectations, functional requirements, non-functionals and other value-adding activities for a Product in a prioritized list known as the Product Backlog. The Product Owner also manages the game budget.
The Scrum Master, a one-person player role, facilitates the Scrum Team during the game by blasting any impediments that block the Team. The Scrum Master also teaches the Team in understanding and playing the game, making sure the rules of the game are well understood and inducing the continual desire to become better players.
The game is played in timeboxed iterations, Sprints, containers that allow the Team to focus on achieving the next level, the Sprint Goal, with minimal outside disruptions. The Team elaborates selected Product Backlog Items (PBI’s) in a list of actionable work, the Sprint Backlog. To guarantee quality, the Team (of Developers) defines a set of ‘Engineering Standards’ and is empowered for technical implementation. To guarantee the “fitness for purpose” of the increment of software at the end of each Sprint, the Team is accountable for delivering work that complies with a ‘Definition of Done’ that needs to incorporate organizational standards.
Sprint length is kept equal for reasons of game cadence and for metrics like the Velocity. The exact length should be tuned to the ability to capitalize on emerging business opportunities (turning them into increments of working software), but also depends on how long a Team can work without consulting the stakeholders. A software development Sprint typically takes 1-4 weeks.
The nature of the Game
The Team (of Developers) inspects itself, and adapts by sharing right-time planning information in a short, 15 minutes, daily meeting called the Daily Scrum. The Team acts as a self-organizing unit performing all development activities required to turn PBI’s into ‘Done’ software, where ‘development’ applies to test cases, TDD tests, code, documentation, integration work, etc.
Overall progress of a Sprint is measured and visualized on a Sprint Burndown chart, i.e. a graph with the daily accumulation of remaining work. In order to continuously measure and adapt to reality and achieve the best predictability possible in complex product development, the remaining work is re-estimated every day.
Measuring and forecasting
The dynamics of the game are controlled via closed-loop feedback mechanisms.
The Product Owner packages PBI’s and monitors Release progress on a Product Burndown chart, the accumulation of remaining work over the packaged PBI’s. The measured progress of past Sprints gives the Product Owner the forecasted delivery date.
A Sprint forms an ‘inspect & adapt’ cycle that wraps the 24-hours ‘inspect and adapt’ of the Daily Scrum. The Sprint cycle starts with a Sprint Planning meeting at which the Team (of Developers), upon a right-time planning principle, inspects Product Backlog Items prioritized and clarified by the Product Owner to the extent of the Velocity. Velocity being the amount of PBI’s that was turned into ‘Done’ working software the previous Sprint. The Product Owner adds right-time functional refinements. The Team (of Developers) continues the Sprint Planning session with right-time analysis and design work on the selected items. The result is a forecasted list of technical tasks, the Sprint Backlog.
At the end of a Sprint, a collaborative Sprint Review session over the completed increment is organized. Input, feedback, remarks and comments of all stakeholders is gathered. The Product Owner will assess it and process/prioritize it appropriately in the Product Backlog. In the following Sprint Retrospective session the Scrum Team looks back at all aspects of the past Sprint in order to adjust, experiment and improve their operations in the upcoming Sprint.
Game ends – You win
The collaborative Sprint Review provides the Product Owner with the best information to decide whether the Product will be shipped, and whether more Sprints are required upon the balance of delivered Value and remaining effort.
You might also want to read the Scrum Guide, by game originators Jeff Sutherland and Ken Schwaber.