Agile in non-software development

This blog collects a number of sources on the subject of applying Agile methods to areas other than software development.

The Agile Manifesto

"The 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:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


That is, while there is value in the items on the right, we value the items on the left more."

Agile Glossary for non-software

Agile Term

Definition

Agile Processes

A development methodology based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams and is collectively regarded as highly efficient.

Backlog

Also knows as "product backlog," the backlog is a prioritized list of user stories and defects in order from most valuable to least valuable for a system. Backlogs include both functional and non-functional user stories as well as technical team-generated stories.

Change Management

Change Management includes change related activities such as issue tracking, document tracking, and process workflows that enable development teams to control the overall process.

Cross-Functional Team

Team comprised of members with all functional skills necessary to complete a project from start to finish.

Distributed Development

Development teams that work on the same project but are located across multiple locations.

Epic

A user story which describes a large amount of customer value and needs to be broken down into many smaller user stories.

Iteration

Microcosm of a traditional Development Life Cycle, each of which produces working solution. Iterations can be as long as 3 months but are more typically between 1 to 4 weeks. See sprint.

Planning Poker

A consensus-based technique for estimating; mostly used to estimate effort or relative size of tasks in development.  Planning Poker is useful for building team cohesion and for fostering self-organizing teams.

Product Backlog

The backlog owned by the Product Owner.

Product Owner

A role originating from Scrum, but has now been widely adopted independently of Scrum. A product owner manages the product backlog, addresses questions that arise during development and signs off on work results. The product owner guides the team with what should be done and when the final product should be shipped. The Scrum team then balances out the product owner’s decisions by deciding how much work should be involved in an individual sprint and estimating the amount of time necessary to complete the task.

Scrum

Agile development project management framework based around sprints and is generally comprised of a Scrum Team, Product Owner and Scrum Master. The framework of Scrum leaves most development decisions up to the self-organizing Scrum team, where decisions are reached as a whole team.

Scrum Master

Person trained to facilitate daily Scrum meetings, remove impediments, oversee the team’s progress through the process and track Scrum team updates.

Self Organizing

A team, usually found in Scrum, that manages itself through various means of communication and reoccurring structured meetings. Self organizing teams solve development issues together as a whole and decide the best solution depending on the various team members.

Sprint

Scrum specific word describing iterations.

Sprint Backlog

Plan for development team to map out implementation of features for an upcoming sprint.

Sprint Planning

A meeting for Scrum Teams, Scrum Masters and Product Owners where the Product Owner describes priority features to the team. The Scrum Team gets enough of an understanding about the tasks discussed that they are able to choose which ones to move from the product backlog to the sprint backlog.

Retrospective

Meeting held at the end of every sprint review to reflect on what went well during the sprint and what can be improved upon during the next sprint. Sprint retrospectives are valued as necessary parts of inspecting and adapting, and allow development teams to plan for future output.

Sprint Review

In the sprint review, teams go over what stories were completed during the iteration and demonstrate those stories for stakeholders and the product owner.

Stand-up

Daily Meetings that are meant to quickly and efficiently resolve obstacles that any team members may be experiencing.

Story Points

Relative scale of effort required by a team to implement a user story.

Task Board

A physical or electronic board representing the state of tasks in a current sprint, often divided into "to do," "in progress" and "done."

User Stories

Used with Agile methodologies for specifying requirements and presented as an informal statement of the requirement (usually fitting on a 3x5 index card).