The book itself doesn’t talk about Agile development in pure theoretical terms, it provides insight on how Scrum teams function by using examples and clear explanations. The first chapter starts with, A Week in the Life of a Scrum Team, providing a short overview of what it is like to be a part of a Scrum team.
The Elements of Scrum covers the issues with waterfall development and the history of Agile development, including a detailed examination of the Agile Values and Principles of the Agile Manifesto. Chirs and Louise add their insights and examples as they walk through the Values and Principles, and then proceed to make The Business Case for Agility.
I found the case somewhat simplistic – necessary to make the example clear – but Chris and Louise seem to agree, stating that, “We’ve barely scratched the surface of agile development as a tool for the creation of business value…”
The book quickly moves into an inside look at Scrum itself, including A Brief History of Scrum and a walk through the various Scrum Roles, including the Team Member role. Chris and Louise make an interesting point about the difference between being an individual contributor and a Scrum team member, quoting a student from one of their Certified ScrumMaster workshops: “Being a scrum team member isn’t about getting your job done, it’s about getting the job done.”
The book takes you inside a Scrum team’s inner workings, including planning and executing a sprint, daily scrum (stand-up) meetings, sprint reviews, and the retrospective. The book provides in-depth coverage of key Scrum artifacts such as the product and sprint backlogs, information radiators like the sprint and release charts, the task board, the definition of done, user stories and acceptance criteria. They even cover a topic you don’t read much about: terminating a sprint, most often called because of an event happening outside of the team.
The book doesn’t shy away from another software development reality: those in charge need to have some type of projection of when the software will be complete. As Chris and Louise state, “The real goal of creating estimates is to provide some measure of predictability of schedule. This is why we create estimates: to inform business decisions, which ultimately creates more value.”
Where I thought this book really came through was on the subject of estimating and planning. This was a pain point for me to understand early on in our Scrum adoption, and I would have been grateful to have the examples and insight put forth in The Elements of Scrum
I particularly enjoyed the example of “Agile Islands,” as it provides an excellent basis for understanding Scrum’s use of relative sizing versus time estimates, giving a good example of why relative sizing works, noting that, “while we are bad at absolute sizing, we are good at relative sizing.”
The explanation used as a follow-up is also excellent:
“The trick is to use a two-step process. First, assign relative sizes to all of the work items. The size indicates how much work there is to do. Second, do a couple of work items and measure how long they actually take. Armed with this measured amount, the relative sizes assigned to all of the other items can now be used to provide the desired predictability of schedule.”
If you’ve ever wondered why Agile development uses numbers in the Fibonacci sequence, The Elements of Scrum
Since the book relies on examples of actual experiences to illustrate how Scrum works in practice, it naturally gives an inside look at The Team Estimation Game, and techniques such as planning poker.
The book closes discussing a variety of supporting practices, such as release planning, the use of personas, story mapping, refactoring, pair programming and test-driven development.
If you are looking for one book that provides a solid foundation for understanding Agile development and Scrum, including an “inside look” at how Scrum teams plan and operate, I highly recommend The Elements of Scrum

0 comments
Post a Comment