Term
|
Definition
A fifteen-minute daily meeting for each team member to answer three questions:
1. "What have I done since the last Scrum meeting? (i.e. yesterday)"
2. "What will I do before the next Scrum meeting? (i.e. today)"
3. "What prevents me from performing my work as efficiently as possible?"
The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far outside these constraints. This meeting is also referred to a “stand-up”. It is important that all participants remain standing during this time to encourage brevity. The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive. |
|
|
Term
|
Definition
| Removal of anything that prevents a team member from performing work as efficiently as possible. Each team member has an opportunity to announce impediments during the daily Scrum meeting. The ScrumMaster is charged with ensuring impediments get resolved. ScrumMasters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting. |
|
|
Term
|
Definition
The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog.
During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities. |
|
|
Term
|
Definition
A product backlog item that describes needed functionality and the associated business value. It also contains the acceptance criteria for the work. Typically follows the format:
As a , I need , so that |
|
|
Term
| Product Backlog Item Effort Estimate |
|
Definition
| Some Scrum practitioners estimate the effort of product backlog items in ideal engineering days, but many people prefer less concrete-sounding backlog effort estimation units. Alternative units might include 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 the distinction that product backlog item effort estimates are not estimates of duration. Also, estimates at this level are rough guesses that should never be confused with actual working hours. |
|
|
Term
| Product/Project Burndown Chart |
|
Definition
| 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. The scope of this chart spans releases; however, a release burndown chart is limited to a single release. |
|
|
Term
|
Definition
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. |
|
|
Term
|
Definition
| The transition of an increment of potentially shippable product from the development team into 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. The release balances functionality, cost, and quality requirements against date commitments. |
|
|
Term
|
Definition
| In Scrum, the release burndown chart is a "big picture" view of a release's progress. It shows how much work was left to do at the beginning of each sprint comprising a single release. The scope of this chart is a single release; however, a product burndown chart spans all releases. |
|
|
Term
|
Definition
The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner in the following ways:
• 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. |
|
|
Term
|
Definition
| A Sprint is an iteration of work during which an increment of product functionality is implemented. Fixed Sprint timeboxes allow the team to better plan each iteration, allow for predictability in longer term planning, and help establish a rhythm of delivery for the team. The sprint starts with a 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. |
|
|
Term
|
Definition
| 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 product backlog items. |
|
|
Term
|
Definition
A sprint burndown chart (or "sprint burndown graph") depicts the total task hours remaining per day. This shows you where your team stands with respect to completing the sprint backlog. The X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal engineering hours).
To motivate the team, the sprint burndown chart should be displayed prominently. It also acts as an effective information radiator. Ideally the chart burns down to zero by the end of the sprint. If the team members are reporting their remaining task hours realistically, the line should bump up and down chaotically. |
|
|
Term
|
Definition
| Sprint goals are the result of a negotiation between the product owner and the development team. 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. While some specific product 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. |
|
|
Term
|
Definition
| The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint. Often new backlog items are defined during the meeting. This portion of the sprint planning meeting is time-boxed. 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. This portion of the sprint planning meeting is time-boxed as well. |
|
|
Term
| Sprint Retrospective Meeting |
|
Definition
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.
Kelley Louie (Certified Scrum Practitioner) 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." |
|
|
Term
|
Definition
| In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours. A Task Card is a simple way to track these items. Team members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the sprint burndown chart. Tasks should be sized such that they can be completed in 1-2 days. |
|
|
Term
|
Definition
| Entire team (5-9 people) work in one room and have agreed to spend most of their time together. |
|
|
Term
|
Definition
| Team members do not have defined roles, but contribute their skills to help the team achieve their sprint goals. |
|
|
Term
|
Definition
| Each Team Member is responsible for managing their own work and the team is collectively responsible for deciding who will work on which tasks. They also are responsible for dealing with conflict, setting team norms, and committing to the scope of work each sprint. |
|
|
Term
|
Definition
| In Scrum, velocity is the rate at which a team COMPLETES product backlog items in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. Once established, velocity can be used to plan projects and forecast release and product completion dates. |
|
|
Term
|
Definition
| This is a tool through which the team tracks the progression of tasks during a sprint. Typically, the team will define categories for tasks such as Not Started, Work In Progress, Ready to Test, and Complete. |
|
|
Term
|
Definition
| The Product Owner for the Team works with Team during each day, attends the Daily Scrum, participates in Sprint Reviews, and is readily available for questions/concerns/impediment removal. |
|
|
Term
|
Definition
| Software tools that track things such as Product Backlog, Sprint Backlog, Tasks, Burndown Charts, etc. |
|
|
