The Agile Primer
Agile projects build software incrementally, typically using short iterations of 1–4 weeks, to keep development aligned with changing business needs.
How is agile development different from other methodologies?
Instead of a single pass,
6–18 month
release that predicts all requirements and risks up front:
Agile adapts to frequent feedback by delivering working, tested code every
1–4 week
iteration:
What are the different roles in an agile team?
The
scrum master
is a facilitative servant leader who helps the team stay true to their practices so they can make and meet commitments. Responsibilities include:- Enable close cooperation across all roles and functions
- Remove blocks and shield the team from disturbances
- Work with the organization to track progress and re-factor structures and processes of the organization
- Ensure agile's inspect and adapt processes are leveraged, including daily stand-ups, planning meetings, demo and review, and retrospectives
- Facilitate team meetings and decision-making sessions
The
product owner
drives the product from the business perspective. Responsibilities include:- Define the requirements and prioritize their value
- Determine the release date and content
- Take an active role in iteration and release planning meetings
- Ensure the team is always working on the most valuable requirements
- Represent the voice of the customer
- Accept stories that meet the team's definition of done and defined acceptance criteria
How does an agile team plan their work?
An agile team works in iterations to deliver user stories.
The team plans stories into their iteration based on each story's backlog prioritization and size.
The team uses their capacity (how many ideal hours available to work on tasks), to decide how much scope to plan into the iteration.
Why should I care about story points?
- Points: Define how much the team can commit to
- Capacity: Defines how much an individual can commit to
What is a user story?
A user story is a requirement that defines what functionality a user needs. It can take two formats:
- As a <User Role> I want <Functionality> so that <Business Value>
- In order to <Business Value> as a <User Role> I want <Functionality>
During release planning, user stories are given a rough size estimate using a relative scale like points.
During iteration planning, the story is broken down into tasks.
Agile is very disciplined about producing useful, realistic estimates.
What is the relationship between a user story and tasks?
A user story talks about the what–it defines what a user needs.
A task is how the functionality will be implemented. Stories are implemented by tasks. Real work is more granular than stories. Each story is really a collection of tasks.
We wait to break stories into tasks until the story is planned for the current iteration. Elaborating details just-in-time takes advantage of learning and feedback.
Tasks are estimated in hours, typically sized between 2–12 hours.
Stories are validated with acceptance tests.
When is a story done?
Teams determine what done means. Criteria can include:
- All tasks completed (dev, test, doc)
- All acceptance tests running and passing
- Zero open defects
- Accepted by the product owner
- Could be delivered to users
Teams define their definition of done and commit to completing all stories to that definition during each iteration.
What is acceptance criteria?
The criteria which define the functionality, behavior, and performance required by the feature for it to be accepted by the product owner or customer.
The role of acceptance criteria is to define what
done
is, so that development knows when they have completed the story. If there are areas of the story you don't want to leave for development to define, then write an acceptance criteria. For example, if you feel strongly about how error messages should be worded, you may provide a design document to explain the format and wording of error messages, or you can write acceptance criteria for each story that may generate an error message to specify the message wording.How are requirements defined?
Requirements are defined as a user story with acceptance criteria and tasks to implement the story.