Unlock Agile: 5 Steps to Mastering Agile Development

Like most buzzwords, "agile" means different things to different people. So, what do we mean when we say "agile?"

Agile is a process for creating and delivering digital experiences. It may refer to:

• Agile marketing
• Agile design principles
• Agile project management
• Agile development 

If you work on a digital team, you'll find value in the agile methodology. Whatever your role, agile provides opportunities for improving how you work:

For Marketers

Use the agile methodology to deliver better digital experiences. Test, iterate, and improve

For Designers

Use the agile methodology to add focus and clarity to user experiences

For Project Managers

Use agile project management to improve scope management and clarify requirements

For Developers

Use agile development to deliver working software faster

At EDUCO, we adopted the agile process in 2014. Since then, we've seen major improvements in our design and development process:

• Our estimates are more accurate.
• We no longer struggle with scope management on large projects.
• Our clients understand the technical implications of their feature requests.
• We've standardized basic components of our websites, empowering the team to use development time on more valuable enhancements and custom features.
• Clients, developers, and project managers are happier.

We've had an amazing experience with agile, and we believe you can, too. So, we put together this Agile Development Guide — it gives you everything you need to understand agile, with tactics you can try starting today. 

What are you waiting for? Let's dive in.

What is the Agile Methodology?

To understand the term, let's start with historical context. The agile methodology began as a process for developing software. In 2001, a group of thoughtful developers were looking for a way to improve how they worked. Together, they introduced their Agile Manifesto:

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.

Fast-forward about a decade. What started as a software development manifesto has been distilled into a concrete working process. We've provided a step-by-step walkthrough of the agile methodology, with tips for applying each step within your organization.

Here's an overview of the main process tools we use in agile development:

• Every morning, the team meets for a Daily Standup — a 15 minute progress check-in at the start of the day.
• Team members work on feature requests, which are written as User Stories — the user story format keeps us focused on business value.
• User stories are managed in the Project Backlog — a flexible tool used to prioritize and track progress.
• Stories are organized into Sprints — during a sprint, the team develops and tests specific stories from the backlog.
• At the end of each sprint, the team provides a Demo — key stakeholders experience the completed stories firsthand.

Let's take a closer look at how to use each of these agile tools.

The Daily Standup

The standup is a daily meeting for your immediate team. It starts at a specific time each morning, and it lasts no more than 15 minutes. It's a daily discipline to foster communication, focus, and productivity for your team.

Why should you use the daily standup?

The standup gets everyone on the same page before the day begins. It's a way to check in with your team members and gauge progress. And it's a way to check in with yourself — to see how your work is progressing and set your to-dos for the day.

Once you start using the standup, you'll never wonder "what are we working on?" or "what am I working on?" With the standup, you'll limit long meetings and reduce interruptions. Glorious!

How does the daily standup work?

Pick a set time every day. For us, it's 9:30AM. Plan to meet for 15 minutes, max. 

During the meeting, each team member shares what they're working on with the group. Use this format:

• "Yesterday I worked on..."
• "Today, I'm working on..."
• "My barriers are..." or "No barriers."

Throughout the meeting, one person is the facilitator. This team member is responsible for noting challenges, barriers, and opportunities. After everyone has finished their standup, the facilitator breaks down next steps. This person will say things like:

• "Ryan, you mentioned that you hit a barrier on ticket #1275. Can you work with Michelle to solve it together?"
• "Paul and Claire, it sounds like you're both working on parts of the checkout experience. Why don't you schedule some time to review your work later today?"

Once your team gets comfortable with the process, you won't rely on the facilitator as often. Other team members will step up when they're needed.

User Stories

A user story is a feature request that follows a specific format:

As a [type of user], I want [some feature] so that I can [have some benefit, achieve some goal]

For example:

As a content marketer, I want a blog post template so that I can add and edit blog posts

Why should you write User Stories?

Every project includes feature requests. So, why take the trouble to write them as user stories? User stories keep us focused on what matters most: delivering value to users. User stories are a framing tool. They help us put features in perspective.

User stories answer three key questions: who, what, and why?

• Who is the feature for?
• What is the feature?
• Why is it needed?

A typical features wishlist only addresses the "what?" — as in, "what are the requested features?" And it may include some of the "how" — "how should this feature work?"

But user stories include the essential dimensions of "who?" and "why?" User stories remind us that every feature is for a person. And every feature needs a reason for being. Through user stories, you'll experience more thoughtful and accurate website planning.

User Stories and Related Tasks, organized in the myEDUCO Project Backlog

How do you write User Stories?

The first step to writing user stories is to use the format:

As a [type of user], I want [some feature] so that I can [have some benefit, achieve some goal]

Practice writing your features as user stories. Here are three examples of common website features written as user stories:

• Events: As a front end user, I want an events calendar so that I can find events that interest me.
• Products: As a front end user, I want a digital product catalog so that I can find products relevant to me.
• Metadata Tools: As a marketing manager, I want metadata optimization tools so that I can bulk update website metadata.

3 Tips for Writing Better User Stories

1. Be specific. Split large stories into smaller stories wherever possible.

At EDUCO, we often split large stories into smaller ones. The "Product" feature is a perfect example. Let's say we're building a website for an industrial parts manufacturer. They have 2000 products in an online store. How would we tackle this?

Let's start with a basic story:

As a front end user, I want a digital product catalog so that I can find products relevant to me

So, that describes that catalog itself. But there's more. What about the content managers who need to add and edit products? For them, we need a story like this:

As a content manager, I want a product template so that I can add and edit new products

And what about the product categories? In most product-based sites, we need dynamic product categories. We'll cover that with a story like this:

As a content manager, I want flexible product categories so that I can add and edit new product categories

2. Avoid too much technical detail. Define stories with business value.

This one can be a real challenge for clients who have in-depth features wishlists. Someone on the team usually has a defined idea of how a feature should work — the nuts and bolts. This is highly valuable information. But keep in mind that the person proposing the idea rarely understands the technical implications of their request.

Don't struggle over technical details. Instead, push your stakeholders to convey the business reason for their feature request. What are the business level requirements that would make this feature work?

In agile development, the business requirement or business acceptance test is called the "Definition of Done," or DoD. Here's an example of a DoD for a more technical user story. Note how the DoD doesn't contain any technical specs. It's just a description of what will work for the user.

User Story: As a content manager, I want a product template so that I can add and edit new products

Definition of Done: 

1. There is a content template called "Products."
2. It contains fields for all the relevant content from our product catalog, which display on the website.
3. It also connects to the product categories so that each product can be categorized.
4. When a content manager updates product content, they do it in one place in the template.
5. That change appears in all relevant displays throughout the site.

User Story Card, including the Definition of Done

3. Remember, user stories don't cover everything.

Whenever you're planning a project, the question of "coverage" will come up. The question goes something like, "How many user stories do we need? We want to make sure we're covered for all the features, design, and content that we want."

Here's a few things to consider.

• User stories are best used for feature requests. So, if there is a feature that provides value to a specific user, you'll probably need a user story for it.
• User stories do not cover aspects of design and content. You'll want to use different deliverables for expressing design and collecting content. For design, we use style guides and wireframes. For content, we use content templates.
• You can tie these deliverables to user stories in the form of tasks — more on this below. 

The Project Backlog

In the agile methodology, the project backlog represents the project priorities. It's a visual plan that you present to project stakeholders for feedback. Once approved, the backlog is your project tracker. The team builds, tests, and completes stories in the backlog. You present completed stories from the backlog during the project demo.

Your backlog format depends on the tools you use. If you're using notecards, the project backlog is a literal board. If you use project management software, the backlog is part of the interface. Don't have a project management tool? Working with remote team members? You can also create your project backlog in a spreadsheet. 

A project backlog in myEDUCO, our Drupal-based agile project management software

Why do you need a project backlog?

Many projects have multiple stakeholders. And every project has a few different business objectives. The project backlog drives consensus among all stakeholders. Everyone works together to prioritize stories.

For project managers, the backlog is critical for managing project scope. Once approved, the backlog is the scope of work. Each additional story means a scope change. Scope changes impact timeline and budget. 

It's easier to say, "that story isn't in the approved backlog" than to say, "that feature request will cost more money."

The backlog isn't just for stakeholders — it's for developers, too. The development team estimates the size of each story. They can advocate for important stories during the planning process. Through the backlog, they communicate their insight to other team members.

Engage your stakeholders in your project backlog. In myEDUCO, we encourage client comments on each user story

How to create a scope estimate in the project backlog

As your team starts writing user stories, you enter them in the project backlog. Once you're done writing stories, you're ready to start estimating and prioritizing. 

We don't recommend estimating stories with hours. Instead, we use story sizing. A story can be small, medium, large, or epic. At first, it can be challenging to assign story sizes. But once you've done a few projects with user stories, you'll learn what works for your team. 

Part of this is getting the "feel" for story sizing, which comes with experience. But if you have advanced time tracking, you can measure performance more accurately. Do you have a project management tool that lets you track hours to each story or task? Awesome. After a project, you can look back at your hours and see how you performed against your story size estimates.

A preliminary guide to story sizing

Here's a breakdown of how we estimate story size at EDUCO.

Small Story

Avg. Hours

4 or less

Example

As a front end user, I want social media integration so that I can share content to social media

Sizing Tip

If you're writing a lot of small user stories, they may work as tasks in a larger story

Medium Story

Avg. Hours

8

Example

As a content manager, I want a Services template so that I can add and edit new services.

Sizing Tip

A medium story can be completed by one developer in a single day.

Large Story

Avg. Hours

12

Example

As a front end user, I want a media hub so that I can find content resources relevant to me.

Sizing Tip

Large stories have more volatility. They usually require more than one team member. Your avg. hours may vary.

Epic Story

Avg. Hours

20+

Example

As a front end user, I want to have a shopping cart so that I can add products to my cart.

Sizing Tip

Consider splitting an epic story into separate, smaller stories.

Unknown Story

Avg. Hours

Unclear

Example

We want to integrate with a 3rd party product information management software that we'll be purchasing at the end of the quarter.

Sizing Tip

We can call it out, but without documentation and technical requirements that is the extent we can understand it.

Sprints

A sprint is a timeboxed effort in which the development team completes a specified number of user stories. At the end of the sprint, the team presents a demo of completed stories. A typical sprint includes 2 weeks of work, followed by a demo.

Each story is built, tested, and finished within a single sprint.

Sprints organized in the myEDUCO Project Backlog

Why do you need development sprints?

Sprints provide a practical framework for chunking your development work. They provide clear deadlines and milestones for getting work done. By giving a demo after each sprint, you engage stakeholders in the development process. You get feedback on stories as they are completed.

Through sprints, you focus on completing small parts, getting fast feedback, and improving as you go.

How do you plan web development sprints?

Once you have your list of user stories in the project backlog, it's time to start planning Sprints. Here's a few guidelines for efficient website planning meetings:

• Meet for 3 hours. Take a 5 minute break every 55 minutes
• No checking email. If you really need to, you have to leave the meeting to do it
• The backlog always needs more work. See something you could do? Speak up and volunteer to do it

We recommend two different meetings for planning your sprints. 

1. Backlog Planning Meeting

The team creates the sprints and assigns stories to sprints. This happens before any web development work begins. During this meeting, your focus is the whole project.

Guidelines for creating sprints

• Any missing stories? Add them
• Any stories that need to be split up? Split them up
• Any setup stories that need to be completed first? Add them to the first sprint
• Any stories that have clear direction and are important to stakeholders? Prioritize them
• Any stories that need more direction and detail? Flag them and put them in later sprints

Guidelines for reviewing sprints

• Can each sprint be completed in 2 weeks?
• If not, which sprints are looking "heavy?" Can you move stories to a lighter sprint?
• If all the sprints are looking too "heavy," it might be time to add another sprint
• Once the sprints are balanced, prioritize the stories within each sprint

2. Sprint Planning Meeting

The team adds detail and assigns the work within a given sprint. This happens at the beginning of each sprint. During this meeting, your focus is the specific sprint.

Guidelines for planning your development sprint

• Any stories that need more technical detail? Add tasks to them
• Do all tasks have acceptance tests? If not, write acceptance tests
• Do all tasks have due dates? If not, add them
• Who will complete specific tasks? At first, let developers volunteer. If no one volunteers, you can start assigning tasks
• Are there any barriers to completing stories or tasks within the sprint? If so, you need to remove up these barriers ASAP, since the team is about to work. If you can't remove the barriers within one day, switch the story with one that is ready to work — usually from from a later sprint.

Tasks

Tasks are technical units of work to be completed and verified by the development team. They are the small component parts of a user story. A typical story divides into 3-7 tasks.

Tasks in progress, preparing for project launch

Why do you need tasks?

User stories communicate business value. To deliver on a story, the development team needs technical detail. In the agile methodology, there are many ways to add detail to stories and verify their completeness. Each team does it a little differently. At EDUCO, once we've written our user stories, we break stories into tasks. 

How do you write tasks?

Once you have your user stories written and prioritized, you're ready to start working on tasks. It helps to write tasks in a session with your team. Once the basic work plan is ready in the project backlog, experienced developers can make tasks quickly and efficiently.

Think of tasks as the granular steps needed to complete a story. If you want to get more specific — and we certainly do — you'll describe what needs to be done to complete the task. We call this the acceptance test.

Here's an example of how to create tasks and acceptance tests for a user story:

As a content manager, I want a product template so that I can add and edit new products

Tasks & Acceptance Tests

Collect Existing Content

1. Client has supplied a spreadsheet of all products to be entered into the website
2. Client has supplied product images in Google Drive
3. All product image names are referenced in the spreadsheet

Review Existing Content

1. Review spreadsheet and identified any potential QA issues
2. Identify at least three product use cases to be used for wireframing

Create Wireframe(s)

1. Create wireframes for product experience
2. Development team has reviewed and approved wireframes
3. Client has reviewed and approved wireframes

Build Content Type

1. Create build spec from wireframes
2. Create content type (template) in CMS
3. Add content for at least 5 example products

Import Products

1. Create feed for product import
2. Add product images to proper directory
3. Run product import, check errors, refine

Want to Learn More About the Agile Methodology?

This guide to agile development is just the beginning. If you're considering agile for your business — or for your next project — we'd love to show you how it's done.

As part of our commitment to agile development, we've built myEDUCO. It's our Drupal-based agile project management platform.

Why not take a tour of myEDUCO? We'll show you how our agile process adds value to every client project.

Let's Talk About Agile