Confirmed users
1,193
edits
Scrum/Guide: Difference between revisions
no edit summary
(My "Scrum Guide", now in Wiki form.) |
No edit summary |
||
| (10 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 6: | Line 6: | ||
* The product backlog '''is''' a wishlist | * The product backlog '''is''' a wishlist | ||
* The product backlog '''is''' collaborative. Executives, developers, testers, etc. can all contribute to it. | * The product backlog '''is''' collaborative. Executives, developers, testers, etc. can all contribute to it. | ||
** Either by writing backlog items, or by influencing the product owner to write backlog items | ** Either by writing backlog items, or by influencing the [[#Roles|product owner]] to write backlog items | ||
==Roles== | ==Roles== | ||
| Line 14: | Line 14: | ||
** The product owner '''does''' set direction | ** The product owner '''does''' set direction | ||
* 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 ("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 25: | Line 47: | ||
** Instead, Cohn suggests Scrum teams take a different perspective | ** Instead, Cohn suggests Scrum teams take a different perspective | ||
*** Work as normally | *** Work as normally | ||
*** Use Scrum data (e.g., the burndown chart) to estimate the team's development velocity | *** Use Scrum data (e.g., the [[#Burndown_Chart|burndown chart]]) to estimate the team's development velocity | ||
*** Use this velocity to [http://blog.mountaingoatsoftware.com/wp-content/uploads/predictingwherewefinish.jpg estimate the number of tasks that can be completed by | *** Use this velocity to [http://blog.mountaingoatsoftware.com/wp-content/uploads/predictingwherewefinish.jpg estimate the number of tasks that can be completed by the deadline] | ||
* | * For this video, it is safe to mentally replace the term "release backlog" with "product backlog" | ||
==Estimating== | ==Estimating== | ||
| Line 48: | Line 70: | ||
** This should be something that the team can fall back on. The team should feel confident in saying, "Funding dried up, but at least the last release does XYZ and does it completely." | ** This should be something that the team can fall back on. The team should feel confident in saying, "Funding dried up, but at least the last release does XYZ and does it completely." | ||
** The product created by a Sprint will not do everything, but it should provide a complete user experience | ** The product created by a Sprint will not do everything, but it should provide a complete user experience | ||
*** For example, imagine a product that allows users to share media. At the end of one Sprint, photo support is completed but video support is not. The sortware released at the end of this Sprint should allow the user to create an account, log in, and click "Post a photo" to post a photo. No link for posting | *** For example, imagine a product that allows users to share media. At the end of one Sprint, photo support is completed but video support is not. The sortware released at the end of this Sprint should allow the user to create an account, log in, and click "Post a photo" to post a photo. No link for posting videos should be provided, because in this imagined situation video upload is not completed yet. | ||
*** It would make little sense to build, say, photo upload support before building user login. That would create an incomplete user experience. | *** It would make little sense to build, say, photo upload support before building user login. That would create an incomplete user experience. | ||
==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. | |||