The Agile Primer

Print this topicEmail this topic

How is agile development different from other methodologies?

Agile projects build software incrementally, typically using short iterations of 1–4 weeks, to keep development aligned with changing business needs.

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

Agile teams

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 in agile?

Defined as: The user story, the acceptance criteria, and the tasks to implement the story.

Feedback

Please send us your feedback regarding our help site. For feedback regarding the Rally product, click here to open a support case or click here to submit a new feature request
English
By submitting this form, you accept the Mollom privacy policy.
© 2014 Rally Software Development Corp | Legal