Terminology used for Scrum

Terminology used for Scrum

Stakeholders
Stakeholders have investment in the product being developed, but are not directly related to the development of the product. Stakeholders make up the Customer Team that provides input into the product backlog.

Product Owner
A single person who has the final authority representing the customer's interest in prioritizing and answering questions about stories. This person must be available to the team at any time, but especially during the Sprint Planning Meeting and the Sprint Review.
on-site customer and stakeholder representative are also the terms for product owner

Acceptance Test
An acceptance test is a test that verifies that the story respects the Product Owner acceptance criteria. These acceptance criteria should be included with each story as early as possible in a Sprint, or before taking the story in sprint is ideal. Using acceptance criteria is essential to confirm a team-wide understanding of each story. For teams who have automated testing setup, it is recommended to automate the acceptance test cases so that the status of the story can be verified anytime in the future by simply running its acceptance test.

Agile Modeling (AM)
Agile Modeling is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices. At a more detailed level AM is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner.

Burn-down Charts
Burn-down Charts show work remaining over time (work remaining is the Y axis and time is the X axis).Burn-down can be charted for the story points remaining in a release (see Release Burn-down) or hours remaining in a sprint (see Sprint Burn-down). Displaying burn-down charts in the team area provides high visibility of progress to the team and its stakeholders."

Continuous Integration [CITA]
A fully automated build and test process that allows a team to build and test their software many times a day on a shared code stream.

Daily Scrum
A short daily meeting where each team members stands and answers the three questions:
1. What have I done for the sprint since the last Scrum meeting?
2. What will I do for the sprint before the next Scrum meeting?
3. What impediments are preventing me from performing work for the sprint as efficiently as possible?
All side discussions should be tabled until after the meeting.
Anyone can attend the daily scrum meeting, but the meeting should be focused on the work of the sprint team.

Epic [A Large Story]
A Story that is too large or complex to be estimated. Before scheduling for a sprint, such large stories should be broken down into smaller sub stories, some of which may also have to be broken down further. The hierarchical relationships among the sub stories that result from repeated breakdowns is valuable because it provides product context for each sub story and allows progress on the entire epic to be tracked.

Impediment
Anything that prevents a team member or the team as a whole from performing work as efficiently as possible is an impediment. The Scrum Master is typically responsible for clearing impediments.

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Operational Backlog
The Operational Backlog, or Parking Lot, is contains the work required in the product that may not have direct customer value and would not be written or represented by the customer. Examples of items in the Operational Backlog are code re-factoring or other technical debt, environmental or infrastructure setup, ongoing maintenance activities, etc. When pulling work for a sprint, balance the work in the Product Backlog with the work in the Operational Backlog.

Product Backlog
The Product Backlog is the as yet unfulfilled customer requirements, expressed as a prioritized list of stories. Although there are multiple sources of inputs to the Product Backlog, it is the sole responsibility of the Product Owner to prioritize the Product Backlog.

Pair Programming
When two team members work on a programming task together. The driver role implements the code while the navigator role identifies potential issues, enforces standards, and anticipates next steps. The team members should alternate roles frequently. Pair programming has been shown to increase quality, and thereby eventually pay for itself in future productivity. Pair programming also reduces the impact of losing a developer, because the people who paired with him/her have acquired much of his/her knowledge. Pair programming is also a valuable technique for bringing a new developer up to speed more quickly.
Potentially Shippable Product Increment
Software with sufficient quality and utility to be potentially shippable. Each sprint should deliver a potentially shippable product increment. This has two consequences
1. Quality – Untested software is not potentially shippable, so the software produced in each sprint must be fully tested.
2. Utility – Unusable software is not potentially shippable. Implementing horizontal slices of stories will lead to sprint deliveries with functionality that cannot yet be used because the slices could not be delivered for every architectural component in the same sprint. On the other hand, implementing vertical slices will make the functionality delivered by every story in every sprint potentially usable, at least for some user scenarios.

Re-factoring
Systematic transformations that change the structure of code without changing its execution behavior. It is recommended that the code being re factored is well covered by automated Unit Tests - the higher your unit test coverage, the more likely that you will discover when a re factoring inadvertently changes the behavior of an object. Re-factoring is useful for retrofitting design patterns into code when the implementation of new stories would tend to violate Once And Only Once or other design principles.

Release
The transition of a potentially shippable product increment from the development team into routine use by end customers. Releases typically happen when one or more Sprints has resulted in the product having enough value to outweigh the cost to deploy it. Releases can also be used as milestones in the development of a product - these are generally call internal releases.

Release Backlog
The Release Backlog is a subset of the Product Backlog assigned to a specific release for a specific time period. It can be represented as a line in the Product Backlog, or as a separate backlog artifact.

Release Burn-down Chart
The Release Burn-down Chart presents the progress of a release by showing how many story points of work has been done and how many are left to do in the release at the beginning of each Sprint. Note that the total number of story points in a release is not necessarily constant over the lifetime of the release.

Scrum Master
The Scrum Master is a facilitator for the team. Rather than manage the team, the Scrum Master works to assist the team in the following ways:
• Help the Product Owner drive development in order to maximize ROI.
• Facilitate team creativity and empowerment.
• Remove impediments.
• Drive improvements to the process, engineering practices and tools.
• Keep information about the team's progress up to date and visible to all parties.

Scrum of Scrums
A Scrum of Scrums is a team of compose of one or more Team Members of regular Scrum teams. The usual purpose of a Scrum of Scrums is to identify, track, and resolve dependency issues across the represented teams.

Spike
When a story cannot be accurately estimated due to a lack of knowledge (rather than sheer size like an epic), a common approach is to define a story for attaining the knowledge required to provide a good estimate. Such a story is a spike.

Sprint
An iteration of work during which a potentially shippable product increment is implemented. Currently, the recommended practice is 2-weeks.

Sprint Backlog
The set of Stories from the Product Backlog that the team has committed to complete during the Sprint.

Sprint Burn-down Chart
A Sprint Burn-down Chart depicts the total task hours remaining per day. This shows you where the team stands regarding completing the Sprint Backlog. The X-axis represents days in the Sprint, while the Y-axis is estimate hours of effort remaining.

Sprint Planning Meeting
The Sprint Planning Meeting is where the team negotiates with the Product Owner what they will commit to doing in the next Sprint.
The team generally proceeds as follows
1. Determine how many work hours each member will be available during the Sprint.
2. Select stories from the Product Backlog in the order determined by the Product Owner,
3. Break each story into tasks, and
4. Estimate how many hours it will take to complete each task,
5. Repeat steps 2 through 4 until the cumulative number of task hours gets as close to the total available work hours as the team is comfortable committing to.
Breaking the stories into tasks often requires asking the Product Owner clarifying questions. Sometimes, the team can suggest changes in which stories are selected for a sprint to the Product Owner which will make implementation easier."

Sprint Retrospective
The Sprint Retrospective is held at the end of every Sprint after the Sprint Review. The Team Members and Scrum Master meet to discuss what went well and what to improve in the next Sprint.

Sprint Review
The Sprint Review is where the Team Members demonstrate the software that they produced during the Sprint to the Product Owner and Stakeholders. Feedback is welcome, but since the meeting is usually constrained to an hour or less, detailed discussions should be tabled until after the meeting. Note that software completed days before the Sprint Review can and should be demonstrated to the Product Owner and interested Stakeholders earlier in order to be able to negotiate acceptance criteria.

Sprint Task
A Sprint Task (or Task) is a standalone unit of work needed to complete a storie, generally estimated to take between 1 and 18 hours. Team Members select their own tasks. They update the estimated number of hours remaining on each of their tasks on a daily basis. The Sprint Burndown Chart displays the sum of all the updated estimated hours each day.

Stakeholder
A Stakeholder is a person or another team who has an interest in some or all of the Stories that a team is implementing, but is not the Product Owner.

Story
A Story is a customer requirement expressed in the form: "As a , I want so that ." A story should be small enough to estimate its size, comfortably implement in a Sprint and have a single priority.

Story Points
Relative estimate of size of a Story. A recommended practice is to use Fibonacci Numbers or powers of 2 to avoid trying to estimate too finely.

Team Member
Anyone working on any Sprint Tasks. Typically includes developers, testers, documentors. Technical Debt Technical Debt is the difference between doing something the "right-way" versus getting it released quickly. This must be minimized. Minimal technical debt is the single most important factor in delivering a maintainable system. Keeping technical debt to a minimum and re-factoring (below) creates a system that is easier to change and is responsive to customer needs. Technical Debt may be prioritized in the Operational Backlog.

Test Coverage
The percentage of the code which is executed by at least one automated unit test. Usually measured as the percentages of lines of code.
Test Driven Development (TDD)
A programming technique where you:
1. Write a unit test for a class,
2. Make sure the unit test fails,
3. Write the most straight forward, principled code to make that unit test pass,
4. Repeat step 1 through 3 above until the suite of unit tests form a satisfactory specification of the class.

Unit Test
An automated test that verifies a single responsibility of a single unit of code.

Velocity
Velocity is a history-based estimate of how many Story Points a team can complete in one Sprint.
velocity is usually estimated by averaging the number of Story Points the team completed over the last several sprints. Once the velocity for a team stabilizes, the velocity can be used to forecast release and product completion dates, assuming that both the team composition and the number of story points in the releases also remain stable.

The Classic Story of the Pig and Chicken

Here
Pig roles are considered core team members. Performers. People who “do” work
The roles of both Product Owner and the Scrum-Master are considered to be pigs in the team instead of chicken.
A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to “getting things done.” Their “eggs” are a renewable resource.