Skip to main content

Quick and Dirty Guide to Agile Project Management

This summary provides information on the key tenants of agile project managment and explains how it can be used to manage digital services projects.

Download PDF

Agile Principles

What does this mean for contracts for Agile managed projects? It means that ideally, contracts for these projects are best structured as smaller (modular) pieces of a whole to allow flexibility for any needed changes and ensure delivery of working product/software/code.

How are Agile Projects Managed?

You need a roadmap! Roadmap n. [rōd-map] A plan of action for how a product or solution evolves over time. The key to a well-managed agile project is a solid roadmap. Roadmaps are built by product owners, and include large areas of product functionality, and when features will be available. To build a roadmap, product owners take into account market trajectories, value propositions, and engineering constraints. Once these factors are reasonably well-understood, they are expressed in a roadmap as initiatives and timelines. Below is a very simple roadmap for a product team. The initiatives are in blue and timelines are indicated by the milestone-markers in red.

Agile Roadmap

Each part of the roadmap will be broken down into smaller parts called Epics, which will have User Stories (both explained later). Since the Teams in Space website is the first initiative in the roadmap, we’ll want to break down that initiative into epics: e.g. Travel Stories, Travel Reservations, Promos… and then into User Stories for each of those epics: e.g. for Travel Reservations: Book Travel, Book a hotel…

Epics graphic showing user stories for three items: User Management, Travel reservations, Promos and Offers

The product owner then organizes each of the user stories into a single list for the development team. The product owner may choose to deliver a complete epic first (left). Or, it may be more important to the program to test booking a discounted flight which requires stories from several epics (right). See both examples below.

Epics graphic showing a single epic strategy versus a multiepic strategy

What may influence a product owner’s prioritization?

While the product owner is tasked with prioritizing the backlog, it’s not done in a vacuum. Effective product owners seek input and feedback from customers, designers, and the development team to optimize everyone’s workload and the product delivery.

Managing Development

Epics=Iterations=Sprints (in Scrum). Each of these have user stories. Graphic showing agile methodology with 3 sprints of plan, design, build, test, review, launch

What is a user story?

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a (type of user), I want (some goal) so that (some reason).

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

User stories create the product “backlog,” which is a prioritized list of work. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The key to an agile process here is that the development team pulls work from the product backlog as there is capacity for it, either continually (e.g. kanban) or by iteration (e.g scrum) instead of being assigned it based on a set schedule.

What Size Should A User Story Be?

A story should be small enough to be coded and tested within an iteration—ideally just a few days. When a story is too large, it is called an epic. Backlog items tend to start as epics when they are lower priority. User story size guides:

Too broad:

Too detailed

Just right

When Do I Add Detail to a User Story?

Acceptance criteria provide the Definition of Done for the story. As details about the story evolve, capture the critical ones as acceptance criteria. The product owner should list as many acceptance criteria as possible in order to clarify the intent of the story. Regardless of how detailed the acceptance criteria are, the team should have a conversation about them and adjust the acceptance criteria to capture the results of the discussion. Once an iteration has begun, testers can formalize acceptance criteria into acceptance tests.

Who Uses User Stories?

What Are The Top Mistakes That People Make?