Ken Schwaber and Jeff Sutherland have posted an update to the Scrum Guide this year. Here is a link to the summary of the changes. In case you prefer, here is a summary of the changes:
1. The team doing the work is now called the ‘Development Team‘, and all members of the team are called Developers whether their expertise is in programming, testing, UX design, technical writing, etc. This is to emphasize that the team works together to ‘develop’ the software.
2. The team no longer ‘commits‘ to accomplishing the sprint goals, they ‘forecast‘ what they will complete and the expectation is that the plan will adapt as they learn more. The main reason for this is at times stakeholders have engaged in committment bashing, penalizing the team for breaking commitments even when the circumstances were beyond the team’s control. This is an acknowledgement that it’s nearly impossible to predict a 100% accurate plan until the team has enough information – which is usually when they are doing the actual work. We can, however, forecast accurately enough to make a plan with flexibility baked in.
3. Scrum doesn’t require use of a burndown chart specifically, only that the amount of work remaining in a sprint is summed and known daily, and trending towards completion is maintained throughout the sprint.
4. Release planning is valuable but isn’t required; it depends on your circumstances.
5. The Sprint Backlog is the Product Backlog items selected for the sprint plus the plan for delivering those. Here is a diagram from scrum.org which illustrates what is considered the sprint backlog:
6. The product backlog is now ‘ordered‘ instead of ‘prioritized‘; this is to emphasize that there are many factors that go into the order of the backlog including ROI but also logical order, dependencies, gaining knowledge, and other factors unique to the situation.
Edit: Here is a link to the Scrum Guide
Thanks for the nice summary, Jill. Your blog post made me want to go and read the actual document (I had not read it before). In addition to linking to the official summary, you should also link to the scrum guide itself.
I would like to hear your opinion on some of the changes. For example, do you like calling everyone on the team “developer”? That might make for a good future blog post. Personally that’s a bit too touchy-feely for my tastes, but in the context of talking about the scrum process it makes sense. However, I wish they had chosen “team member” or “contributor” rather than “developer” since “developer” has certain connotations that the others do not.
Interesting. I really liked the concept of calling all members of the team as Developers so that the “Whole team approach” is imbibed.
But on the Contrary, As Bryan suggested, even I’m curious to hear perspective from folks about “calling everyone developers” in an agile team. Seems to be an interesting debate..
Thanks Bryan and Prasanna. Bryan, I added a link to the Scrum Guide.
In general, I like the change to call the cross-functional team the ‘Development Team’ just for that reason – to helps to reinforce the concept of the cross-functional whole-team approach when it comes to working towards sprint goals. The team is collaborating to ‘develop’ the software for release. I also agree with Bryan that the word ‘Developer’ has been synonymous with, for example, ‘Programmer’ or ‘Coder’ for so long that it will be difficult to change, and honestly I’m not sure how well it will catch on. Lisa Crispin and Janet Gregory refer to this in their book on Agile Testing, to reinforce the fact that the whole team owns quality, so that was the first place I saw this change referenced. That description resonated with me, for other reasons – Agile Testers ‘develop’ automated test cases which we consider code, etc.
So to sum it up: I like the change and actually think it is a good one, but think it remains to be seen whether it will catch on.