May 21, 2019
An Agile Development Glossary
Sophilabs applies an Agile approach to development in order to organize our teams and the work we do on a daily basis. If you're new to Agile, though, all the jargon we use can make us sound like we're speaking an entirely different language! We've put together a glossary of Agile terms to help keep everyone on the same page.
The conditions each user story or task must meet in order to be considered "done" from a business point of view. This usually means that the work item is functioning as expected and satisfies the corresponding user or customer needs.
Agile is an approach for developing software that stresses the importance of collaborating with the customer, adapting to changing requirements, continuously delivering software, and working on a self-organizing team that is always seeking to improve its efficiency.
Formally titled the Manifesto for Agile Software Development, this document outlines the principles and values behind the Agile software development movement. It was written by 17 software developers in 2001 who were frustrated with contemporary development practices that favored complicated contracts, highly detailed planning, and extensive documentation that impeded progress. The four Agile values are: 1) Individuals and interactions over processes and tools 2) Working software over comprehensive documentation 3) Customer collaboration over contract negotiation 4) Responding to change over following a plan.
A visual representation of how much the team has accomplished over a period of time. Time is shown on the horizontal x-axis, and the scope of the project that has been completed (and that is still pending completion) is represented on the vertical y-axis.
Also standup, daily standup. A brief meeting (up to 15 minutes) held every day in which the team evaluates the progress they've made during the last 24-hour cycle against their set sprint goals, looks for improvement opportunities, and ensures any progress impediments are being handled.
Definition of Done (DOD)
The shared agreement and understanding of the quality and working elements the software must have in order to be releasable. These elements are agreed upon by the development team and the Product Owner.
Also epic. A user story that's too big to estimate accurately and will usually take more than one sprint to complete. Typically an epic story will be broken down into smaller, more manageable user stories before it is included in the sprint backlog.
A list of all the elements the product will need, usually ordered from top to bottom in a way that best prioritizes value added for the Product Owner and stakeholders.
The process by which product teams and stakeholders collaborate to establish a clear vision of the product and its functionalities. This occurs at the very beginning of a project before a single line of code has been written. To learn more about Product Inception, check out our series of posts that delve into the topic.
Member of a Scrum team who is in charge of maximizing the customer's value perception. They achieve this by ensuring the team is aligned with all product needs expressed through user stories and by prioritizing them in the Product Backlog so customers receive what they want most early in the value-creation process.
An Agile framework that enables development teams to organize themselves and their work. A Scrum team is made up of the Product Owner, Scrum Master, and Team Members. Work is completed in short cycles called sprints, and progress is measured by managing a Product Backlog.
One of the regular meetings of each sprint, such as the Daily Scrum or Standup, Sprint Planning Meeting, Sprint Review, or Sprint Retrospective.
The team member responsible for guiding the team through the Scrum process, coaching them through any challenges and providing support when individual team members encounter obstacles. They're the team's Scrum and Agile expert.
Also cycle, sprint cycle, or iteration. The period of time (usually two weeks) in which the team has taken on a number of user stories to complete.
The list of user stories that the team will complete on a given sprint. It's also a subset of the Product Backlog itself– usually the most refined user stories from the top of the list, which can be completed within a single sprint.
Meeting a Scrum team holds at the beginning of each sprint to determine what user stories they will commit to during that sprint and how they will distribute the tasks.
Meeting held by the Scrum team and stakeholders at the end of the sprint. The development team shows stakeholders their progress during the last sprint and collects feedback from stakeholders.
Meeting held by Scrum team (without stakeholders) after the Sprint Review to determine what strategic changes to make to improve performance.
Anyone outside the development team who is interested in the success of the product. Stakeholders could include customers, investors, or product users.
A collaboratively-built visual representation of the product and its features. It's usually created during the Product Inception process in order to determine how a product is going to function, and is often updated as the product evolves and more is known about it. The features and functions on the Story Map feed user stories into the Product Backlog. To learn more about using a Story Map during Product Inception, take a look at our post.
The ideal pace of work for the team, which they should be able to sustain indefinitely. This is a highly productive pace that at the same time avoids burnout.
A piece of work that represents a non-functional (with no direct business value) requirement needed for the product to fulfill its goals. A task is often outlined as part of a functional requirement (such as a user story), but in some cases it may exist directly on the Product Backlog.
Generally speaking, a board that represents a group of work items to be completed during a given timeframe, organizing work items into one of (at least) three columns: To Do, In Progress, and Done. A task board makes progress visible and keeps team members accountable to each other and to stakeholders. A Scrum Board or a Kanban Board are framework-specific examples of a Task Board.
Characterization of a type of user who will interact with the software product. User personas are often utilized to come up with user stories. To learn more about user personas, check out our post on persona analysis.
An outline of a product requirement, often representing a feature that a given user needs in order to accomplish a specific goal. A common formula for user stories is "As a [type of user], I want [a feature or functionality], so that I can [achieve my goal]."
Agile Glossary by The Agile Alliance
Sims, Chris and Hillary Louise Johnson. Scrum: A Breathtakingly Brief and Agile Introduction. Columbia: Dymaxion, 2012.