See Persona.
-
-
Contributors
The Agile Dictionary is sponsored by Agile Learning Labs, and maintained by an amazing group of volunteers.
User Story
Also: Story
A user story is an agile requirement expressed from the user’s point of view, stated as a sentence or two of plain English.
A user story typically fits on a note card and may include a title and a short description. The user story is not intended to capture every aspect of the feature to be developed. As described by proponents of Extreme Programming, it is meant to serve as a placeholder for a dynamic conversation between the product owner or customer, and the agile team.
While a user story may take any form that works for the team, here is one format that has become popular:
As a [type of user] I want to [do something] so that I [get a benefit].
The product backlog is comprised of user stories. Large user stories are known as epics, which may be decomposed into user stories as they near implementation. In the broadest terms, a user story that is appropriately sized for implementation is one that is a) implementable, and b) for which an acceptance test may be written.
Background Of The Term
The User Story originates with Extreme Programming and replaces the more traditional Use Case, which was a more abstract and discursive model that usually focused more on the requirements for building the product and less on the user.
Further Learning
User Stories – Agile Alliance – glossary
User Stories with Examples and Template – Atlassian Agile Coach – article
Introduction on how to write User Stories – femke.design – video (5 minutes)
Values
The Agile Values were formalized by a group of software development pundits who gathered in Snowbird, Utah in February, 2001 to attempt to collectively grok what all of them recognized as an emergent trend in their various practices. What they emerged with was a new name for what they did–Agile–and an Agile Manifesto that consisted of Values and Principles, and an organization that would eventually be formalized as The Agile Alliance.
The Values (taken directly from the Agile Manifesto) are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Etymology
The Agile Values were originally stated in the Agile Manifesto.
Posted in v
2 Comments
Velocity
The rate at which an agile team completes work, used not to measure progress per se, but to accurately estimate the team’s capacity for future iterations and guide the team and product owner in planning upcoming iterations.
In the first iteration, a team has no velocity; they take a flying guess at how much work they will complete. But from iteration two onward, velocity is derived from the amount of work the team completed in the previous iteration or iterations.
Different teams use different units of measure for estimating work and determining velocity, some of the most common being: story points (Scrum), craft units (XP), ideal days or hours. The team may determine its velocity by averaging the amount of work completed to date over the number of iterations completed (work/time), or simply by taking the amount of work completed in the previous iteration and carrying it forward.
The data used to determine a team’s velocity may be documented on the project Burn Down and Burn Up charts.
Background of the Term
Originally, advocates of Extreme Programming estimated in terms of Load Factor, which was the inverse of velocity, being time/work. “We think velocity is the simpler term, so Load Factor is falling out of use,” Robert C. Martin wrote in 2000. Kent Beck said much the same in his 2000 book, Planning Extreme Programming: “We used to use load factor a lot in planning, but since then we have learned that it’s easier to just use velocity.”
Further Learning
An Agile Learning Labs blog post: https://agilelearninglabs.com/2009/01/track-velocity-not-time-spent-on-tasks/
Posted in v
2 Comments
Waterfall
The traditional method for developing and delivering software. The Waterfall method breaks a project into discrete stages:
- requirements-gathering
- design
- coding
- testing
In a Waterfall process, each step must be completed before moving on to the next, and all steps in the process must be completed before any value is delivered to the customer. You can see from the illustration exactly where the name “waterfall” comes from–the development process literally “flows” from one stage to the next.
The waterfall method is characterized by what Agilists call “big design up front.”
Etymology:
Winston W. Royce first presented what is now known as the traditional Waterfall method in a 1970 paper, Managing the Development of Large Software Systems, at an IEEE event called WestCom. He didn’t use the term Waterfall, but he did describe a sequential process where each phase is completed before the next is begun. Royce went on to say that of course one would never want to run a software project this way—but somehow, the description of what would come to be known as Waterfall was taken out of context and widely adopted, to the extent that it is now considered standard operating procedure for large software projects.
Posted in w
2 Comments