Each developer must feel comfortable committing to the work she’s signed up for. And since the team has a “we’re all in this together” attitude, everyone needs to be comfortable with the overall commitment of the team.
You’ve learned the mechanics of Scrum, and how to use the basic Scrum pattern to get your team working together. But there’s a big difference between Scrum theory and getting teams to actually build software on a live project. How do you set up your Scrum team to succeed? How do you get everyone to strive for the same goals? In other words, now that you understand what Scrum is all about—self-organization and collective commitment—how do you actually get your team to do it in real life?
In this chapter, you’ll learn about the practices that many Scrum teams use for planning their sprints. You’ll see how user stories can help you really understand exactly what your users need from the software, and you’ll use story points and project velocity to get a good handle on how much work your team can do in a sprint. And you’ll learn how to use two valuable visualization tools, burndown charts and task boards, to keep everyone on the same page.
You’ll also learn why these practices and the basic pattern for a Scrum project aren’t enough for your team to achieve “hyper-productivity” or “astonishing results.” We’ll revisit the Scrum values, and you’ll learn how to assess if your team and company culture match ...