Terms used in the ScrumWorks® documentation:
Ken Schwaber recommends estimating the effort of Backlog Items in days, but many of us prefer less concrete-sounding backlog effort estimation units. Alternative units might be Story Points, Function Points, or "T-shirt sizes" (1 for small, 2 for medium, etc.). The advantage of vaguer units is they're explicit about this fact: Estimates at this level are rough guesses that should never be confused with actual working hours!
Whatever your preference, ScrumWorks allows you to specify your choice of backlog effort estimation unit when you create a product or change its properties. Note that Sprint Tasks are distinct from Product Backlog Items and Task effort remaining is always estimated in hours.
Backlog Item
In Scrum, a Product Backlog Item ("PBI", "Backlog Item", or "Item") is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog Items are decomposed into one or more Tasks.
See also Backlog Effort Estimation Unit
Backlog Planner
A window in the ScrumWorks Desktop Client that helps you define, prioritize, and schedule work.
The Backlog Planner helps you manage the Product Backlog, including adding, removing, and updating backlog items, prioritizing them, associating them with tasks and committing them to Sprints.
The Backlog Planner consists of two sub-windows: one displays the Committed Backlog and the other the Uncommitted Backlog.
Click here for more information.
Burndown Charts
Burndown Charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward.
The Scrum books define a Sprint Burndown Chart to see daily progress, and a Product Burndown Chart to show monthly progress. ScrumWorks provides these, and also an Enhanced Product Burndown Chart.
Committed Backlog
In Scrum, work that has been scheduled or completed resides in the Committed Backlog.
ScrumWorks displays the committed backlog in the left side of the Backlog Planner. Product Backlog Items are organized by the Sprint in which they are implemented. Within a given sprint the Backlog Items are listed by order of priority, with the highest-priority item listed first. You can drag and drop them to reprioritize them, reschedule them to another Sprint, or move them to the uncommitted backlog just as easily as rearranging index cards on your desk.
Daily Scrum Meeting
A 15-minute daily meeting for each team member to answer three questions:
Ken Schwaber recommends that this meeting take place first thing in the morning, as soon as all team members arrive.
ScrumWorks supports the daily Scrum meeting with the Sprint Detail View and the Impediments Window. Teams which have previously been lax about updating their task time estimates are encouraged to do so during the daily scrum meeting with the Sprint Detail View projected on the wall for all to see.
Impediments
Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the Daily Scrum Meeting. The ScrumMaster is charged with ensuring impediments get resolved. At Danube, our Scrum Master often arranges sidebar meetings when impediments cannot be resolved on the spot.
Impediments Window
The Impediments Window lists a summary of product-wide impediments.
The third question of the Daily Scrum Meeting is "What, if anything, prevented you from doing your work as efficiently as possible?"
ScrumWorks allows you to declare your impediments so they don't fall through the cracks.
Point Person
The Point Person is the individual who has volunteered to ensure a Task gets done, whether or not this involves enlisting others from the Team.
ScrumWorks tasks can be unassigned, or associated with a Team Member acting as the Impediments Window.
Danube (and others) generally recommend that a team member delays signing up for a task until (s)he's actually ready to start working on it.
Product
Ken Schwaber's word for "project." We find this a little confusing, but use it for consistency with the Scrum books.
Product Backlog
The requirements for a system, expressed as a prioritized list of Backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements.
During a Sprint planning meeting, backlog items are moved from the Product Backlog into a Sprint, based on the Product Owner's priorities.
Please see the Backlog Planner, the Committed Backlog, and the Uncommitted Backlog for related information.
Product Burndown Chart
In Scrum, the Product Burndown Chart is a "big picture" view of a project's progress. It shows how much work was left to do at the beginning of each Sprint.
ScrumWorks provides a basic (by the book) Product Burndown Chart and also an Enhanced Product Burndown Chart.
Product Owner
In Scrum, a single person must have final authority representing the customer's interest in backlog prioritization and requirements questions.
This person must be available to the team at any time, but especially during the Sprint Planning Meeting and the Sprint Review Meeting.
See also Challenges Of Being Product Owner
Release
The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more Sprints has resulted in the product having enough value to outweigh the cost to deploy it. (per Robert MacDonald)
“The product is released to customer or marketplace obligations. The release balances functionality, cost, and quality requirements against date commitments.” (Schwaber/Beedle, Agile Software Development with Scrum, p. 80)
ScrumWorks allows you to define releases and group Sprints and Backlog Items into them. The release inclusion/exclusion feature of the Product Burndown Chart will work properly if you group consecutive Sprints into releases. Releases are designated in the Backlog Planner by dark blue bars in the Uncommitted Backlog, and by the leftmost vertical bars in the committed and uncommitted backlog.
ScrumMaster
The Scrum Master's responsibilities:
Scrum Roles
There are three roles in a Scrum Project:
Scrum Scoreboard
See Joel Adams and Deborah Hartmann's articles.
ScrumWorks Desktop Client
ScrumWorks has two kinds of clients that can communicate with the ScrumWorks Server. The ScrumWorks Desktop Client is the more powerful of the two. Thanks to the magic of Java WebStart, it acts like a regular desktop application program (other than saving its data on the centralized server). Officially the ScrumWorks Desktop Client supports Microsoft Windows, but we've seen it appear to work fine on Linux and Mac OS X (Panther and Tiger) with a few cosmetic flaws.
ScrumWorks Server
ScrumWorks is a multiuser, networked application. The ScrumWorks Desktop Client and the ScrumWorks Web Client both keep all project data on the ScrumWorks Server.
Our easy Windows installer handles all of this for you, but in case you're curious, the ScrumWorks Server is a J2EE application built as an EAR file deployed onto the open-source JBoss application server.
Special legacy customers are using other OS, application server, and database configurations. We encourage users to stick to the standard configuration. We have given up trying to do a full Q.A. cycle on all the alternative configurations, which invariably have their own quirks.
Scrum Works Web Client
ScrumWorks is a multiuser networked application with two types of clients. The ScrumWorks Web Client gives an individual team member quick access to his/her own tasks from any web browser (even without Java) when the full power of the ScrumWorks Desktop Client isn't needed.
The ScrumWorks Web Client supports all browsers we know about. Please contact us if you discover any that don't work.
Sprint
An iteration of work during which an increment of product functionality is implemented. By the book an iteration lasts 30 days; ScrumWorks allows any length Sprint (see Sprint duration discussion).
The Sprint follows a one-day Sprint Planning Meeting. Many Daily Scrum Meetings occur during the Sprint (one per day). At the end of the Sprint we have a Sprint Review Meeting, followed by a Sprint Retrospective Meeting.
During the Sprint, the team must not be interrupted with additional requests. Guaranteeing the team won't be interrupted allows it to make real commitments it can be expected to keep.
Out of practical necessity, some teams choose to bend this rule by declaring some team members 80% available at the outset so they still have some cycles left for "Priority 1" bugs and such. But this is a slippery slope....
Sprint Backlog
Defines the work for a Sprint, represented by the set of Tasks that must be completed to realize the Sprint's goals, and selected set of Backlog Items.
Please see Sprint Detail View
Sprint Burndown Chart
In Scrum (and ScrumWorks), a Sprint Burndown Chart (or "Sprint Burndown Graph") depicts the total task hours remaining per day. This shows you where your team stands regarding completing the tasks that comprise the backlog items that achieve the goals of the Sprint.
To motivate the team, Danube advocates displaying this visibly, so we built it into the SprintDetailView. A manual alternative to this is a physical task board.
Ideally the chart burns down to zero by the end of the Sprint. If your team members are reporting their remaining task hours realistically, the line should bump up and down chaotically. The profile shown below is typical, and demonstrates why the "percentage done" concept of traditional project management breaks down. Assuming we started measuring on July 26, what "percentage done" were we on July 28?
Sprint Detail View
The Sprint Detail View focuses the team during the Daily Scrum Meeting.
It shows the Sprint Goals, the Sprint Burndown Chart, and a list of Tasks for the Sprint. We have found it valuable to project this on the wall, getting the whole team on the same page about where things stand for the current Sprint.
The task table is editable to allow team members to update task estimates, trade tasks, mark them as "Impeded" etc. during the Daily Scrum Meeting.
NOTE: We suggest individual team members update task attributes (such as hours remaining) on their own time from the ScrumWorks Web Client.
Sprint Duration
Ken Schwaber recommends 30 day Sprints.
ScrumWorks allows you to set the begin date and the end date of a Sprint when you create it. It doesn't enforce any particular Sprint Duration (though there is a cosmetic issue with the SprintBurndownChart for unusually short Sprints).
At the very least, we recommend keeping a constant Sprint Duration. A variety of problems occur when you tamper with this, including difficulty in predicting Velocity (hint: there is not a linear relationship between Sprint Duration and backlog effort capacity). See also the "Loss of Rhythm" smell in Mike Cohn's article.
A 30-day Sprint involves the following meeting overhead (in addition to the daily Scrum meetings):
Sprint Goals
Sprint Goals are the result of a negotiation between the Product Owner and the development team.
Meaningful goals are specific and measurable. Instead of "Improve Scalability" try "Handle five times as many users as version 0.8."
Scrum focuses on goals that result in demonstrable product. The Product Owner is entitled to expect demonstrable product (however small or flimsy) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set.
Have your team commit to goals that anyone will be able to see are met (or not met) at the end of the Sprint.
ScrumWorks displays the Sprint Goals in the Sprint Detail View. At Danube Sprint Review Meetings we project these goals on the wall after our demonstrations and ask the Product Owner whether (s)he feels the goals were met.
While some specific Backlog Items may not be done at the end of a Sprint, it should be very unusual for a team not to meet its Sprint Goals. Scrum requires the team to notify the Product Owner as soon as it becomes aware it will not meet its goals.
Sprint Planning Meeting
The Sprint Planning Meeting is a negotiation between the team and the Product Owner about what the team will do during the next Sprint.
The Product Owner and all Team Members agree on a set of Sprint Goals, which is used to determine which Product Backlog Items to commit from the Uncommitted Backlog to the Sprint. Often new backlog items are defined during the meeting. This phase tends to take half a day.
Typically the team will then excuse the Product Owner from the room and break the Backlog Items down into Tasks. The Product Owner is expected to be on call during this phase (previously called the Sprint Definition Meeting?) for renegotiation or to answer questions that affect the time estimates. In our experience it takes the second half of the day to complete this phase of the meeting, and coffee is recommended. Sometimes we insert placeholder Tasks (with rough estimates) for the Backlog Items we don't expect to start working until later in the Sprint.
ScrumWorks supports the Sprint Planning Meeting with the Backlog Planner.
See also Mike Cohn's explanation.
Sprint Retrospective Meeting
The Sprint Retrospective Meeting is held at the end of every Sprint after the Sprint Review Meeting. The Team and ScrumMaster meet to discuss what went well and what to improve in the next Sprint. The Product Owner does not attend this meeting.
The Sprint Retrospective should be time-boxed to three hours.
Kelley Louie (Certified ScrumMaster and Scrum practitioner here at Danube Technologies) writes: "The Sprint Retrospective Meeting is an integral part of the inspect and adapt process. Otherwise, the team will never be able to improve their overall output and not focus on the overall team performance. The ScrumMaster must pay attention to this meeting and work towards resolving the impediments that may be slowing down the team. "
Consider using a Scrum Scoreboard during the retrospective.
Sprint Review Meeting
At the end of each Sprint, the Team, ScrumMaster, and Product Owner meet to see a live demonstration of the work the team has done. (Per Scrum rules, every Sprint, including the very first one, includes some kind of demonstrable, functional product, no matter how frail, incomplete, or ugly.)
The Sprint Review Meeting should be time-boxed to four hours.
At Danube Technologies and the organizations we mentor, we've found it useful to extract an explicit declaration from the Product Owner whether the agreed goals were met. This builds trust and accountability.
During the Sprint Review Meeting, the Product Owner sometimes discovers that the team has misunderstood what she asked for, or that what she asked for isn't exactly what she really wanted. The beauty of iterative development is the opportunity to correct specification errors after each month instead of after years.
The Scrum process accepts the reality perfect requirements specifications cannot arise out of a vacuum. Agile organizations continuously refine requirement specifications (and designs) as the Product Owner learns from the evolution of the product during successive Sprint Review Meetings.
Task
In Scrum, a Task (or Sprint Task) is a unit of work generally between 4 and 16 hours. Team Members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the Sprint Burndown Chart. Tasks are contained by Backlog Items.
Danube encourages splitting a task into several if the estimate exceeds 12 hours.
The ScrumWorks Backlog Planner allows you to create tasks by right clicking the Backlog Item it is part of. A task identified during the Daily Scrum Meeting can also be created with the "new task" button of the Sprint Detail View
Team
A Scrum Team is typically comprised of 6-10 people (though we've also seen good results with teams smaller than 6 people).
For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. At Danube we tend to call them all "developers." Agile practices encourage cross-functionality.
During a Sprint, the Team self-organizes to meet the Sprint Goals. The team has autonomy to choose how to best meet the goals, and is held responsible for them. The ScrumMaster acts as a guardian to ensure that the team is insulated from the Product Owner.
Many agilists advocate putting the entire team in one TeamRoom.
Team Member
An individual on the Team.
In ScrumWorks, a Team Member can be associated as Impediments Window of a Task by doubleclicking the task from the Sprint Detail View or the Backlog Planner. Or you can click on the Impediments Window column of the Sprint Detail View.
Team Members can log in to the ScrumWorks Desktop Client and the ScrumWorks Web Client.
To create new ScrumWorks Team Members, log into the ScrumWorks Desktop Client as "administrator" and use the "User" menu.
Team Unit
The smallest group of people that can produce deliverable product by themselves.
Example:
Source: Dan Rawsthorne
Uncommitted Backlog
In Scrum, work that has been identified but not scheduled (or done) resides in the uncommitted backlog.
ScrumWorks displays the uncommitted backlog as the right side of the Backlog Planner. Product Backlog Items are listed in order of priority with the highest-priority item listed first. You can drag and drop them to reprioritize them, schedule them for a specific Sprints and so on just as easily as rearranging index cards on your desk.
Velocity
In Scrum, Velocity is how much backlog effort a team can handle in one Sprint. This can be estimated by viewing previous Sprints, assuming the team composition and Sprint Duration are kept constant.
Velocity tells you how much work you can get done when planning the next Sprint.
How can Velocity computations be meaningful when Backlog Item estimates are intentionally rough? We've seen that the law of large numbers tends to average out the roughness of the estimates.
ScrumWorks displays Velocity in the Product Burndown Chart and the Enhanced Product Burndown Chart.
Velocity Trendline
The Velocity Trendline depicts the average rate work has been completed in an Enhanced Product Burndown Chart.
This is computed according to you marking Product Backlog Items as done. If a Backlog Item in a Sprint is marked "done", ScrumWorks assumes it was completed in that Sprint. If this is incorrect, move the Backlog Item into the Sprint it was actually completed in. If it was only partially completed in that Sprint, split off that part and create a new Backlog Item for the part that wasn't done then, with new estimates for both.
Work Added Removed Trendline
In an Enhanced Product Burndown Chart, the work added/removed trendline represents Product Backlog Items created, removed, or re-estimated. This is distinct from changes in remaining backlog effort due to work being completed.
- Backlog Effort Estimation Unit
- Backlog Item
- Backlog Planner
- Burndown Charts
- Committed Backlog
- Daily Scrum Meeting
- Impediments
- Impediments Window
- Point Person
- Product
- Product Backlog
- Product Burndown Chart
- Product Owner
- Release
- ScrumMaster
- Scrum Roles
- Scrum Scoreboard
- ScrumWorks Desktop Client
- ScrumWorks Server
- ScrumWorks Web Client
- Sprint
- Sprint Backlog
- Sprint Burndown Chart
- Sprint Detail View
- Sprint Duration
- Sprint Goals
- Sprint Planning Meeting
- Sprint Retrospective Meeting
- Sprint Review Meeting
- Task
- Team
- Team Member
- Team Unit
- Uncommitted Backlog
- Velocity
- Velocity Trendline
- Work Added Removed Trendline
Ken Schwaber recommends estimating the effort of Backlog Items in days, but many of us prefer less concrete-sounding backlog effort estimation units. Alternative units might be Story Points, Function Points, or "T-shirt sizes" (1 for small, 2 for medium, etc.). The advantage of vaguer units is they're explicit about this fact: Estimates at this level are rough guesses that should never be confused with actual working hours!
Whatever your preference, ScrumWorks allows you to specify your choice of backlog effort estimation unit when you create a product or change its properties. Note that Sprint Tasks are distinct from Product Backlog Items and Task effort remaining is always estimated in hours.
Backlog Item
In Scrum, a Product Backlog Item ("PBI", "Backlog Item", or "Item") is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog Items are decomposed into one or more Tasks.
See also Backlog Effort Estimation Unit
Backlog Planner
A window in the ScrumWorks Desktop Client that helps you define, prioritize, and schedule work.
The Backlog Planner helps you manage the Product Backlog, including adding, removing, and updating backlog items, prioritizing them, associating them with tasks and committing them to Sprints.
The Backlog Planner consists of two sub-windows: one displays the Committed Backlog and the other the Uncommitted Backlog.
Click here for more information.
Burndown Charts
Burndown Charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward.
The Scrum books define a Sprint Burndown Chart to see daily progress, and a Product Burndown Chart to show monthly progress. ScrumWorks provides these, and also an Enhanced Product Burndown Chart.
Committed Backlog
In Scrum, work that has been scheduled or completed resides in the Committed Backlog.
ScrumWorks displays the committed backlog in the left side of the Backlog Planner. Product Backlog Items are organized by the Sprint in which they are implemented. Within a given sprint the Backlog Items are listed by order of priority, with the highest-priority item listed first. You can drag and drop them to reprioritize them, reschedule them to another Sprint, or move them to the uncommitted backlog just as easily as rearranging index cards on your desk.
Daily Scrum Meeting
A 15-minute daily meeting for each team member to answer three questions:
- "What have I done since the last Scrum meeting? (i.e. yesterday)"
- "What will I do before the next Scrum meeting? (i.e. today)"
- "What prevents me from performing my work as efficiently as possible?"
Ken Schwaber recommends that this meeting take place first thing in the morning, as soon as all team members arrive.
ScrumWorks supports the daily Scrum meeting with the Sprint Detail View and the Impediments Window. Teams which have previously been lax about updating their task time estimates are encouraged to do so during the daily scrum meeting with the Sprint Detail View projected on the wall for all to see.
Impediments
Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the Daily Scrum Meeting. The ScrumMaster is charged with ensuring impediments get resolved. At Danube, our Scrum Master often arranges sidebar meetings when impediments cannot be resolved on the spot.
Impediments Window
The Impediments Window lists a summary of product-wide impediments.
The third question of the Daily Scrum Meeting is "What, if anything, prevented you from doing your work as efficiently as possible?"
ScrumWorks allows you to declare your impediments so they don't fall through the cracks.
Point Person
The Point Person is the individual who has volunteered to ensure a Task gets done, whether or not this involves enlisting others from the Team.
ScrumWorks tasks can be unassigned, or associated with a Team Member acting as the Impediments Window.
Danube (and others) generally recommend that a team member delays signing up for a task until (s)he's actually ready to start working on it.
Product
Ken Schwaber's word for "project." We find this a little confusing, but use it for consistency with the Scrum books.
Product Backlog
The requirements for a system, expressed as a prioritized list of Backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements.
During a Sprint planning meeting, backlog items are moved from the Product Backlog into a Sprint, based on the Product Owner's priorities.
Please see the Backlog Planner, the Committed Backlog, and the Uncommitted Backlog for related information.
Product Burndown Chart
In Scrum, the Product Burndown Chart is a "big picture" view of a project's progress. It shows how much work was left to do at the beginning of each Sprint.
ScrumWorks provides a basic (by the book) Product Burndown Chart and also an Enhanced Product Burndown Chart.
Product Owner
In Scrum, a single person must have final authority representing the customer's interest in backlog prioritization and requirements questions.
This person must be available to the team at any time, but especially during the Sprint Planning Meeting and the Sprint Review Meeting.
See also Challenges Of Being Product Owner
Release
The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more Sprints has resulted in the product having enough value to outweigh the cost to deploy it. (per Robert MacDonald)
“The product is released to customer or marketplace obligations. The release balances functionality, cost, and quality requirements against date commitments.” (Schwaber/Beedle, Agile Software Development with Scrum, p. 80)
ScrumWorks allows you to define releases and group Sprints and Backlog Items into them. The release inclusion/exclusion feature of the Product Burndown Chart will work properly if you group consecutive Sprints into releases. Releases are designated in the Backlog Planner by dark blue bars in the Uncommitted Backlog, and by the leftmost vertical bars in the committed and uncommitted backlog.
ScrumMaster
The Scrum Master's responsibilities:
- Remove the barriers between the development and the product owner so that the product owner directly drives development.
- Teach the product owner how to maximize Return On Investment (ROI), and meet his/her objectives through Scrum.
- Improve the lives of the development team by facilitating creativity and empowerment.
- Improve the productivity of the development team in any way possible.
- Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
- Keep information about the team's progress up to date and visible to all parties.
Scrum Roles
There are three roles in a Scrum Project:
- Product Owner
- ScrumMaster
- Team
Scrum Scoreboard
See Joel Adams and Deborah Hartmann's articles.
ScrumWorks Desktop Client
ScrumWorks has two kinds of clients that can communicate with the ScrumWorks Server. The ScrumWorks Desktop Client is the more powerful of the two. Thanks to the magic of Java WebStart, it acts like a regular desktop application program (other than saving its data on the centralized server). Officially the ScrumWorks Desktop Client supports Microsoft Windows, but we've seen it appear to work fine on Linux and Mac OS X (Panther and Tiger) with a few cosmetic flaws.
ScrumWorks Server
ScrumWorks is a multiuser, networked application. The ScrumWorks Desktop Client and the ScrumWorks Web Client both keep all project data on the ScrumWorks Server.
Our easy Windows installer handles all of this for you, but in case you're curious, the ScrumWorks Server is a J2EE application built as an EAR file deployed onto the open-source JBoss application server.
Special legacy customers are using other OS, application server, and database configurations. We encourage users to stick to the standard configuration. We have given up trying to do a full Q.A. cycle on all the alternative configurations, which invariably have their own quirks.
Scrum Works Web Client
ScrumWorks is a multiuser networked application with two types of clients. The ScrumWorks Web Client gives an individual team member quick access to his/her own tasks from any web browser (even without Java) when the full power of the ScrumWorks Desktop Client isn't needed.
The ScrumWorks Web Client supports all browsers we know about. Please contact us if you discover any that don't work.
Sprint
An iteration of work during which an increment of product functionality is implemented. By the book an iteration lasts 30 days; ScrumWorks allows any length Sprint (see Sprint duration discussion).
The Sprint follows a one-day Sprint Planning Meeting. Many Daily Scrum Meetings occur during the Sprint (one per day). At the end of the Sprint we have a Sprint Review Meeting, followed by a Sprint Retrospective Meeting.
During the Sprint, the team must not be interrupted with additional requests. Guaranteeing the team won't be interrupted allows it to make real commitments it can be expected to keep.
Out of practical necessity, some teams choose to bend this rule by declaring some team members 80% available at the outset so they still have some cycles left for "Priority 1" bugs and such. But this is a slippery slope....
Sprint Backlog
Defines the work for a Sprint, represented by the set of Tasks that must be completed to realize the Sprint's goals, and selected set of Backlog Items.
Please see Sprint Detail View
Sprint Burndown Chart
In Scrum (and ScrumWorks), a Sprint Burndown Chart (or "Sprint Burndown Graph") depicts the total task hours remaining per day. This shows you where your team stands regarding completing the tasks that comprise the backlog items that achieve the goals of the Sprint.
To motivate the team, Danube advocates displaying this visibly, so we built it into the SprintDetailView. A manual alternative to this is a physical task board.
Ideally the chart burns down to zero by the end of the Sprint. If your team members are reporting their remaining task hours realistically, the line should bump up and down chaotically. The profile shown below is typical, and demonstrates why the "percentage done" concept of traditional project management breaks down. Assuming we started measuring on July 26, what "percentage done" were we on July 28?
Sprint Detail View
The Sprint Detail View focuses the team during the Daily Scrum Meeting.
It shows the Sprint Goals, the Sprint Burndown Chart, and a list of Tasks for the Sprint. We have found it valuable to project this on the wall, getting the whole team on the same page about where things stand for the current Sprint.
The task table is editable to allow team members to update task estimates, trade tasks, mark them as "Impeded" etc. during the Daily Scrum Meeting.
NOTE: We suggest individual team members update task attributes (such as hours remaining) on their own time from the ScrumWorks Web Client.
Sprint Duration
Ken Schwaber recommends 30 day Sprints.
ScrumWorks allows you to set the begin date and the end date of a Sprint when you create it. It doesn't enforce any particular Sprint Duration (though there is a cosmetic issue with the SprintBurndownChart for unusually short Sprints).
At the very least, we recommend keeping a constant Sprint Duration. A variety of problems occur when you tamper with this, including difficulty in predicting Velocity (hint: there is not a linear relationship between Sprint Duration and backlog effort capacity). See also the "Loss of Rhythm" smell in Mike Cohn's article.
A 30-day Sprint involves the following meeting overhead (in addition to the daily Scrum meetings):
- an 8-hour Sprint Planning Meeting (4 hrs per part),
- a 4 hour Sprint Review, and
- a 3 hour Sprint Retrospective
Sprint Goals
Sprint Goals are the result of a negotiation between the Product Owner and the development team.
Meaningful goals are specific and measurable. Instead of "Improve Scalability" try "Handle five times as many users as version 0.8."
Scrum focuses on goals that result in demonstrable product. The Product Owner is entitled to expect demonstrable product (however small or flimsy) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set.
Have your team commit to goals that anyone will be able to see are met (or not met) at the end of the Sprint.
ScrumWorks displays the Sprint Goals in the Sprint Detail View. At Danube Sprint Review Meetings we project these goals on the wall after our demonstrations and ask the Product Owner whether (s)he feels the goals were met.
While some specific Backlog Items may not be done at the end of a Sprint, it should be very unusual for a team not to meet its Sprint Goals. Scrum requires the team to notify the Product Owner as soon as it becomes aware it will not meet its goals.
Sprint Planning Meeting
The Sprint Planning Meeting is a negotiation between the team and the Product Owner about what the team will do during the next Sprint.
The Product Owner and all Team Members agree on a set of Sprint Goals, which is used to determine which Product Backlog Items to commit from the Uncommitted Backlog to the Sprint. Often new backlog items are defined during the meeting. This phase tends to take half a day.
Typically the team will then excuse the Product Owner from the room and break the Backlog Items down into Tasks. The Product Owner is expected to be on call during this phase (previously called the Sprint Definition Meeting?) for renegotiation or to answer questions that affect the time estimates. In our experience it takes the second half of the day to complete this phase of the meeting, and coffee is recommended. Sometimes we insert placeholder Tasks (with rough estimates) for the Backlog Items we don't expect to start working until later in the Sprint.
ScrumWorks supports the Sprint Planning Meeting with the Backlog Planner.
See also Mike Cohn's explanation.
Sprint Retrospective Meeting
The Sprint Retrospective Meeting is held at the end of every Sprint after the Sprint Review Meeting. The Team and ScrumMaster meet to discuss what went well and what to improve in the next Sprint. The Product Owner does not attend this meeting.
The Sprint Retrospective should be time-boxed to three hours.
Kelley Louie (Certified ScrumMaster and Scrum practitioner here at Danube Technologies) writes: "The Sprint Retrospective Meeting is an integral part of the inspect and adapt process. Otherwise, the team will never be able to improve their overall output and not focus on the overall team performance. The ScrumMaster must pay attention to this meeting and work towards resolving the impediments that may be slowing down the team. "
Consider using a Scrum Scoreboard during the retrospective.
Sprint Review Meeting
At the end of each Sprint, the Team, ScrumMaster, and Product Owner meet to see a live demonstration of the work the team has done. (Per Scrum rules, every Sprint, including the very first one, includes some kind of demonstrable, functional product, no matter how frail, incomplete, or ugly.)
The Sprint Review Meeting should be time-boxed to four hours.
At Danube Technologies and the organizations we mentor, we've found it useful to extract an explicit declaration from the Product Owner whether the agreed goals were met. This builds trust and accountability.
During the Sprint Review Meeting, the Product Owner sometimes discovers that the team has misunderstood what she asked for, or that what she asked for isn't exactly what she really wanted. The beauty of iterative development is the opportunity to correct specification errors after each month instead of after years.
The Scrum process accepts the reality perfect requirements specifications cannot arise out of a vacuum. Agile organizations continuously refine requirement specifications (and designs) as the Product Owner learns from the evolution of the product during successive Sprint Review Meetings.
Task
In Scrum, a Task (or Sprint Task) is a unit of work generally between 4 and 16 hours. Team Members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the Sprint Burndown Chart. Tasks are contained by Backlog Items.
Danube encourages splitting a task into several if the estimate exceeds 12 hours.
The ScrumWorks Backlog Planner allows you to create tasks by right clicking the Backlog Item it is part of. A task identified during the Daily Scrum Meeting can also be created with the "new task" button of the Sprint Detail View
Team
A Scrum Team is typically comprised of 6-10 people (though we've also seen good results with teams smaller than 6 people).
For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. At Danube we tend to call them all "developers." Agile practices encourage cross-functionality.
During a Sprint, the Team self-organizes to meet the Sprint Goals. The team has autonomy to choose how to best meet the goals, and is held responsible for them. The ScrumMaster acts as a guardian to ensure that the team is insulated from the Product Owner.
Many agilists advocate putting the entire team in one TeamRoom.
Team Member
An individual on the Team.
In ScrumWorks, a Team Member can be associated as Impediments Window of a Task by doubleclicking the task from the Sprint Detail View or the Backlog Planner. Or you can click on the Impediments Window column of the Sprint Detail View.
Team Members can log in to the ScrumWorks Desktop Client and the ScrumWorks Web Client.
To create new ScrumWorks Team Members, log into the ScrumWorks Desktop Client as "administrator" and use the "User" menu.
Team Unit
The smallest group of people that can produce deliverable product by themselves.
Example:
- 1 dev,
- 1 tester,
- 1 analyst.
Source: Dan Rawsthorne
Uncommitted Backlog
In Scrum, work that has been identified but not scheduled (or done) resides in the uncommitted backlog.
ScrumWorks displays the uncommitted backlog as the right side of the Backlog Planner. Product Backlog Items are listed in order of priority with the highest-priority item listed first. You can drag and drop them to reprioritize them, schedule them for a specific Sprints and so on just as easily as rearranging index cards on your desk.
Velocity
In Scrum, Velocity is how much backlog effort a team can handle in one Sprint. This can be estimated by viewing previous Sprints, assuming the team composition and Sprint Duration are kept constant.
Velocity tells you how much work you can get done when planning the next Sprint.
How can Velocity computations be meaningful when Backlog Item estimates are intentionally rough? We've seen that the law of large numbers tends to average out the roughness of the estimates.
ScrumWorks displays Velocity in the Product Burndown Chart and the Enhanced Product Burndown Chart.
Velocity Trendline
The Velocity Trendline depicts the average rate work has been completed in an Enhanced Product Burndown Chart.
This is computed according to you marking Product Backlog Items as done. If a Backlog Item in a Sprint is marked "done", ScrumWorks assumes it was completed in that Sprint. If this is incorrect, move the Backlog Item into the Sprint it was actually completed in. If it was only partially completed in that Sprint, split off that part and create a new Backlog Item for the part that wasn't done then, with new estimates for both.
Work Added Removed Trendline
In an Enhanced Product Burndown Chart, the work added/removed trendline represents Product Backlog Items created, removed, or re-estimated. This is distinct from changes in remaining backlog effort due to work being completed.