It was suggested that I level set some terminology before I begin writing some more of my detailed posts about Agile. As such I have put together a glossary for your use. I am going to be posting a series of Agile content so if you have any questions about what I mean with a reference you can refer back to this post and get clarity. You will find many of these terms defined in a variety of ways on the internet, but when I use them I mean the definition below. I will try to use links to these terms when appropriate in my other posts.
Agile
A software development
methodology developed by Ken Schwaber and Jeff Sutherland in the mid-1990s. In
short, Agile is a way to execute a project where you prioritize the highest value items of the project and work on them first. To enable this, the cross functional team works closely with a lead (product owner) from the business team, valuing the communication and relationship over a formal requirements document.
Agile Estimation
Features are estimated in terms of there size relative to one another. This is achieved by an approach known as “planning poker” that involves the whole team. Benefits of this approach include the sharing of knowledge across the team, increased consistency through whole team involvement and accuracy of
planning through track record of delivery. See also ‘Velocity’
Backlog
A partially or completely ordered list
of work items in the form of user stories or tasks. Backlogs exist at multiple scopes in the
planning onion, most notably at the levels of each product (line), each release
and each sprint. Effort remaining at any
level of backlog can be tracked in the form of burn-down. (See below.)
Burn-down
A graph of progress over time that represents either ‘Velocity’ or work effort completed.
Calendar Day
The total hours for a give day, which is 24 hours.
Daily Scrum / Daily Stand-ups
To keep the team synchronized, there is a 15-minute meeting every day. Each team member doing work answers the questions:
What I did yesterday?
What am I going to do today?
Do I have any roadblocks, and what are they?
Demonstration / Sprint Close-out / Showcase
A showcase of the features developed during an iteration. This can involve product owners and other stakeholders. Serves as an opportunity to identify new features or change in priorities.
Duration
The number of work periods (not including holidays or other non-working periods) required to complete an activity of other project element. Usually expressed as workdays or work weeks.
Effort
The number of labor units required to complete something (an activity or task, a user story). Usually expressed as ideal engineering hours or days, staff hours, staff days, or staff weeks. Should not be confused with duration.
Epic
A very large user story. Initially product features can be described using an Epic, User Story or stories. Epic user stories are decomposed at the appropriate time so they can be estimated and accepted into a sprint. Epic User Stories are sometimes confused with Features or Themes. While Epic User stories go away, features persist with the product.
Feature
A feature is a tool used to segment a
product. Features add value
(functionality) and address specific needs of product users and
stakeholders. Features are useful for
scaling agile. For large initiatives, a
Product Owner could decide to allocate a feature or features to a particular
Agile team. Features are sometimes
confused with Epic User Stories or Themes.
Epic User Stories go away once they are decomposed. Features always remain as a way to describe a
segment of the product. It's good
practice to associate every user story with a feature.
Ideal Day
The sum of all task hours spent in any given day. The normal amount is 6 hours of time per day.
Information Radiator
A visual information radiator can be a story board, which can be created with note cards. Each card represents a story, and has a priority, estimate, and tasks. The minimum headings on the board should be the following:
Product Backlog
Release Backlog
Sprint Backlog
Stories in Progress with in progress tasks
Completed Stories
Accepted Stories
Burn-down chart
Release Planning Process
The release planning process is essentially concerned with populating, ranking and sizing a backlog of value-based stories for potential delivery during the release.
Retrospective
An opportunity for team members to
reflect on the previous iteration and adapt according to lessons learned. This meeting should provide an open forum for discussion and communication among the team members. The only items discussed outside the team for this meeting are the ones agreed and documented.
SCRUM
A term for a specific type of play in Rugby that is now used to describe a type of agile software development that focuses on making each iteration a mini-project wherein each iteration holds it's own requirements gathering (sprint planning), design, test, and build. SCRUM recognizes other critical project factors such as team dynamic and explores ways to address these in the process.
SCRUM is the most common type of Agile used today and the terms are increasing used interchangably though it should be noted that is incorrect as there are several other types of Agile.
Scrum of Scrums
A meeting in which all Scrum masters
report up to one lead Scrum master a weekly update on the respective
teams. These meeting are no longer than
5 minutes per team, but can include as many a 8 teams. A company that has many dependent projects
running concurrently would use this approach in addition to the normal Scrum
process
Sprint
Sometimes called an ‘iteration’, is a distinct set of time-boxed activities conducted according to its own plan and evaluation criteria, that results in the delivery of releasable product and or system features. Typical sprint lengths are 2 weeks beginning on Wednesday ending on Tuesday. Sprints should never be more than 4 weeks long.
Spike
A time boxed task or tasks performed by a team member with the intent of delivering enough information to estimate a story, which was not estimable before the spike was created. More than one person can work on a spike, but the duration of the spike should not be longer than one sprint.
Story Point
A unit of measure for expressing the overall size of a user story, feature, or other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story that is assigned a one.
Task
A development activity in support of realization of a User Story within a sprint. A good sizing for a task is something that a single team member can achieve in around half a day or less. Sometimes longer tasks can take up to two days, but those would normally be considered oversized for most purposes. This is where the 12 hour maximum is set as a standard.
Technical Debt
When you borrow money that you don't have to buy something today under the expectation you will have the money to repay it in the future, that is called debt. Technical debt is merely creating code or cutting some corners in the development process today under the expectation you will have more time in the future to correct this. The work that must be redone or repaired in the future was typically put in place to meet a business need (such as release schedule). This work must be completed before the project can be considered to complete.
Theme
Themes are used for Product Road mapping, specifically at the release level. While Features are used to describe product segments, themes are used to describe related user stories. These stories may be associated with a single feature, but more likely cross several features or even products. For example a product owner may decide to roadmap a themed release around security, performance, or a new user interface widget. In these cases the high value user stories associated with each theme across all features would move to the top of the product backlog.
User Story
The most common form of an agile requirement, which initially provides a "placeholder for a conversation" about what would be most valuable to a client stakeholder and which evolves to provide more detailed insight and objective completion criteria (including or especially test cases) as the time for its realization approaches. A user story should take less than one iteration to realize fully and be accepted by business stakeholders via the Product Owner; see Epic User Story above.
The user story should include an estimate and a priority. The estimate will be based on work effort, complexity and risk. User stories are typically worded as follows, "As a "role or position", I would like "the service to do something".
Please remember that the something defined should not be technical but rather written in normal language such as "As the customer, I would like to ensure my data is protected from unethical use and hacking."
Velocity
A measure of a team's rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the sprint. It the team completes three stories each estimated at 5 story points, their velocity is fifteen. If the team completes two five-point stories, their velocity is ten.
