Being Agile-ish: Collecting Web Development Requirements as User Stories

Anyone who has worked an Agile project understands how important the backlog is. It is the recipe, the to-do list and the sacred text we refer to on a daily basis. The backlog keeps track of today’s priorities, tomorrow’s dreams and ‘we’d love to do this, but only if we had a million dollars’ ideas. At my company, we’ve been using Atlassian’s JIRA to keep track of the backlog, but going about it in a unique and pretty successful way. Our clients know what to expect and can budget the right amount of time and resources – but can still have a flexible and rapid iteration development cycle.

A traditional Agile backlog is used throughout the project to manage scope and development activities. The backlog is made up of user stories that force all subsequent design to be user centric by building all requirements in terms of the users of the site. User stories can follow the format: “As a USER TYPE, I need to TAKE ACTION, so I can RESULT”. Other user stories may be more technical in nature and will describe environment and development tasks. Sometimes – especially in a company doing it’s own development, a backlog grows organically as users and product managers find bugs, think of new features and are given new priorities by executives. In this scenario, developers can start with a backlog of only a few stories that continues to grow and be re-prioritized. However, any average client working with an agency on a fixed budget needs to understand the scope and budget and timeline before committing to development. Hence, we still need a requirements gathering phase to truly understand the size of the project and how much the client can commit.

Our method is a way of converting requirements into a traditional backlog. First, we introduce the client to Jira and Agile by collecting User Stories as Requirements. This ‘backlog’ is not a traditional implementation backlog, in fact, this is a Jira project that is terminal, and ends when the Requirements Gathering phase is complete. At the end, many of the requirements can be easily transformed into user stories and broken into tasks. Take for example “As a user I can see a list of my orders so I can see my history and drill deeper into details”. This is a Requirement that converts into a implementation User Story exactly as-is. However, something like “As an author, I need to be able to enter information into a CMS with an easy interface”, can go away once a CMS is selected, and won’t need to be transferred to the Implementation backlog. Sure, it’s not pure Agile, but it sets us up to do Agile development in a way that makes a client comfortable. This also puts us in a position where we can estimate a general number of sprints we think it will take to complete these high level tasks – so the client can commit to spending a certain amount of money and time to complete the priority requirements we have identified as a team. During actual development, the sprint team will first move the relevant requirements to the Implementation Backlog. Then, on a sprint by sprint basis, they will break the stories into tasks, and add all the necessary details and specifications as needed. They’ll also add tons of technical, IT and backend tasks to make the user stories stick. We can anticipate these tasks and make sure to consider them when estimating time and budget.

Why this method is interesting

  1. First, based on the business requirements developed from discovery activities like stakeholder interviews, persona development, customer journey mapping, content strategy, SEO analysis, digital analytics analysis and other deep dives we develop high level requirements in the form of user stories to document the requirements. This is instead of a traditional waterfall requirements gathering that results in a static document with lots of elements added for bulk – like those requirements that are interesting at the beginning but won’t become actual features later on. These User Stories stay really high level and don’t get specifications right away.
  2. We create a super simple JIRA workflow and issue types. The only issue types allowed are Requirement, Task and Epic. Everything should be a Requirement, and we’re not on the hook for idnetifying all the technical tasks. But if Technical Tasks come up, we have a place to keep track. Requirements are collected into Epics for easier organization. The workflow is simple. Requirements are open during the discovery and design phase, while the Business Analyst adds, edits and gives them love. They are open to everyone to view and comment, but they are a work in progress. When the team is ready for review with the client, all Requirements become ‘In Progress’. They remain ‘In Progress’ while being tweaked by the whole team. Once approved by the team, they become Approved. Once they are all stories are approved (or deleted) – they can be estimated by our team.
  3. All the relevant Requirements are ready to be moved to the Implementation project. This project is run in an Agile format with sprints. The combined team of the client and the agency makes priorization decisions and can reorganize the backlog throughout the development of the project. If new features come up, the whole team negotiates and decides if it will affect timeline and scope – and if the feature can be added or traded out for a different feature to keep the scope the same size. It is a constant conversation that keeps a fair playing field. The client can add new features that come up, and the agency is protected by keeping within their budget for what they committed to do.

Here’s what we do

  1. Set up JIRA.
  2. Identify Epics
  3. The Business Analyst breaks out individual requirements within each Story Group by taking a first pass to enter draft requirements into the system which may include a series of meetings to further review and define the stories as needed.
  4. Add Page Level and Component Level stories. This activity cannot occur until after the User Experience has been finalized and approved.
  5. Review time. The review consists of a series of meetings and/or individual client review. This is where stories go to the “In Progress” phase of the workflow. The client is required to Approve all stories, which makes it much more interactive, and gives a sense of ownership – since everyone sees exactly what the developers will be seeing as their instructions.
  6. Next, we introduce level of effort scoping to each story. We use story points.
  7. The final round of Requirements Gathering will provide a scope and timeline to complete these stories based on the level of effort scoping. This provides the initial budget and project plan for implementation.

Then comes Implementation. Now that we have a backlog of approved stories, everyone can see into the future and understand what’s coming while still having the benefit of being able to re-prioritize or swap out features. We can move forward as an Agile team, but still be able to budget and scope for our clients.

About Dana

Dana Mandolesi is one cool chick who lives in San Francisco and knows lots about sociology and how people interact with technology. This has led her in all sorts of directions, especially helping companies harness the glory of the web through research, product development and strategy. She has a great love for technology and tries to integrate it into all sorts of things she does.
This entry posted in Dana's Blog. Entry Tags: , , , , , , , , Bookmark the permalink. 

Leave a Reply

Your email address will not be published. Required fields are marked *