Confirmed users
1,193
edits
Scrum/Guide: Difference between revisions
no edit summary
No edit summary |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
These notes provide additional thoughts on [http://www.youtube.com/watch?v=Q5k7a9YEoUI Scrum Master in Under 10 Minutes], an instructional video which provides a surprisingly good overview of the methodology. Topics are discussed in the order that they are presented in the video. | These notes provide additional thoughts on [http://www.youtube.com/watch?v=Q5k7a9YEoUI Scrum Master in Under 10 Minutes], an instructional video which provides a surprisingly good overview of the methodology despite a 90s-era techno soundtrack. Topics are discussed in the order that they are presented in the video. | ||
==Product Backlog== | ==Product Backlog== | ||
| Line 15: | Line 15: | ||
* In some teams, the Scrum master should do little else than coordinate efforts and ensure that the software is high-quality and progressing well | * In some teams, the Scrum master should do little else than coordinate efforts and ensure that the software is high-quality and progressing well | ||
* It is sometimes useful to create subteams within large development groups. In such a setup, high-level requirements might be communicated to a team lead ("Users must be able to visit the site homepage"), with lower-level requirements communicated by the team lead to individual developers ("Users must be able to identify the site by reading the header", "Users must be able to get more information by reading the footer", etc.). | * It is sometimes useful to create subteams within large development groups. In such a setup, high-level requirements might be communicated to a team lead ("Users must be able to visit the site homepage"), with lower-level requirements communicated by the team lead to individual developers ("Users must be able to identify the site by reading the header", "Users must be able to get more information by reading the footer", etc.). | ||
===Responsibilities=== | |||
In general, teams tend to be organized such that each role has the following responsibilities. | |||
* Everyone | |||
** Post ideas (in the form of stories) to the product backlog. "We need to make sure contributors can't post insecure code to the wiki. I'll add a story for that." It is the job of the product owner to act as the filter of all stories that are added. | |||
* The Team | |||
** At each planning meeting, estimate the story points of upcoming stories in the product backlog. | |||
** At each planning meeting, build a sprint backlog based on the priority and complexity (story points) of items in the product backlog. | |||
** Self-select stories to work on during each sprint. "I'd really like to work on this story, because I've done a lot of work with this kind of stuff in the past." | |||
** Develop the software and reach out to the Scrum master when blocked. | |||
* Product Owner | |||
** Represent the customers. Act as their voice. "Administrators really need this feature to be added." | |||
** Own the product backlog. Prioritize the backlog, add and remove stories as necessary, and act as the filter of all stories that are added. | |||
** Approve sprint backlogs created by the team. | |||
* Scrum Master | |||
** Ensure Scrum is being used properly within the project. Answer questions, make recommendations, and coordinate tradeoffs when necessary. | |||
** Organize all meetings. | |||
** Coordinate the work of developers by ensuring that the right people are talking to each other, by ensuring that the work comes together well, etc. | |||
** Ensure that all developers are able to contribute what they are best at, without micro-managing them or deciding how they should do their work. | |||
** Ensure each release adheres to the agreed-upon definition of "done". | |||
==Release Backlog== | ==Release Backlog== | ||
| Line 53: | Line 75: | ||
==Burndown Chart== | ==Burndown Chart== | ||
* A burndown chart can be useful, but without the right tools it can require too much overhead. See the [[ | * A burndown chart can be useful, but without the right tools it can require too much overhead. See the [[Scrum/Tools|Tools]] page. | ||
==Defect Backlog== | ==Defect Backlog== | ||
| Line 103: | Line 125: | ||
==Tools== | ==Tools== | ||
See the [[Scrum/Tools|Tools]] page for a survey of popular Scrum tools and project management platforms. | |||