Creating Epics and User Stories

What is the best approach for translating business objectives and high level features requirements into a manageable development plan your team can tackle?

The first thing you will need is a good tool for tracking tickets and project velocity. This is not the same as more general project management software like Basecamp or Mavenlink, which may be directly integrated with your ticket tracking system or used in parallel by your project managers to augment your development process and interface with clients more easily. [We cover more on essential tools in chapter 4. If you haven’t already read that chapter, you may find it useful to go back and review it first.]

There are lots of good ticket tracking systems out there currently, such as Jixee, JIRA, Pivotal Tracker. At The Development Factory, we use Pivotal Tracker. Herein whenever we refer to Pivotal you can substitute that to mean the tool of your choosing.

Getting Started

Initializing a development project relies on two major steps:

1. Reviewing and estimating the project in terms of user stories, and
2. Transferring stories (and related items) into Pivotal Tracker.

Initial Estimation

Even the best written SOWs cannot possibly contain the level of detail that’s needed to set your developer team on a practical path to project completion.

The task of estimation we’re talking about here is one of bridging the contextual gap between business stakeholders (such as clients and accounts managers) and web developers. It is the process of translating a project concept into an actual project plan. It’s also a little bit of magic.

While the steps outlined below can easily be used to determine project budgets with great precision, typically the budget has already been established by this stage. As the CTO or Production Manager, if you’re lucky, you were consulted upfront about the budget, though time and many other business factors can find you working with what you’ve been given rather than the other way around.

So whether you’re creating a budget or reverse engineering a project plan to fit within the budget, the initial estimation exercise is critical to your project success.

Depending on the size of your organization, the task of estimation may fall always onto the CTO or Director of Production, though larger departments may have Tech Leads or Digital Project Managers (Producers) who can prove capable of handling this task.

It’s a fact that all developers, despite their level of seniority, struggle with estimating tasks honestly and accurately. For this reason it is critical that initial estimation always be executed by the technical leaders of the department. It’s also equally important for the technical leader to be proficient in the type of project being estimated. Often estimates can be wrong because the person estimating does not have direct experience with the technologies, architecture or infrastructure being used. For example someone who typically works on “backend” development should not be estimating a project that is focused on JavaScript and frontend interactions.

When dealing with estimates it’s also a good idea to rely on hard historical data rather than gut feelings. Even the most seasoned managers and technical leaders can misestimate effort on features because they assess the effort from the vantage of their own skill level rather than the skill level of the specific developer who will be doing the work. Employing a good time management software such as My Time Blocks is critical to collecting usable project data.

Step 1 — Gather all related information to the project and its scope.

Do you have everything you need to create the estimate?

Typically this means gathering up:

• a complete outline of all features and deliverables as stated in the SOW;
• any related designs or wireframes already created or comparable existing documents from previous projects to serve as a guide;
• a full understanding of any timelines that have been discussed, promised or documented in the SOW or by the account manager.

Step 2 — Create a written list of the Minimum Releasable Feature Set (MRFS) of the project, or what we refer to as the “epic stories.”

Epic stories group together a set of features or user stories that are conceptually related. Think of them as the bullet points you might see on product packaging:

• “Manage multiple types of users and permission settings!”
• “Integrate with Freshbooks invoicing system!”
• “See the latest updates from all social media!”

Epics are generally only a required step for projects of a certain scale or complexity — where dozens of user stories may comprise a single “feature.”

If your project is small, skip this step and go straight to step 3.

Step 3 — Break apart each epic into its constituent user stories.

User stories describe the user journey across and through a website or application. What can they see? What interactions can they do? What actions can they complete?

There can be many types of users. For example, a “customer” might refer to any person who arrives at a website, whereas an “admin” might refer to a user who has access to the backend system of an application or CMS. In the case where you are building a piece of software, there may even be many types of admins, each with distinct permissions (things they can or cannot do).

The purpose of creating user stories is twofold:

1. To translate features into language that is universally understood by all stakeholder (no more black box!)
2. To inform specific development tasks or tickets; as oftentimes multiple tasks make up a single user story and multiple user stories comprise a “complete” feature or epic.

It’s best to draft epics and stories first on paper or in a separate text editor before transferring to Pivotal. We like to use Evernote for this purpose.

Here are some basic guidelines for documenting and estimating user stories.

• Stories should be created “whole,” meaning that each story should be able to function on its own and be deployed in a way that can be tested by the QA department, by other internal stakeholders, and by the client.
• Stories need to be written in plain language (English) that is understandable by non-technical people. For example, “As an administrator, I can create new system users,” and not “Set up user database table.”
• Estimate the development effort required for each story based on the (skill level of the) developer that will perform that story. Note: there is no one way to do this, just your way — as long as its documented and repeatable! At the end of this chapter we outline the points estimation process that we use at The Development Factory.
• A story should have a maximum of 3 resources assigned to it for responsibility. Having multiple resources responsible for a story should only be so if the story cannot be wholly delivered by any one individual. For example, there needs to be an API call created along with a web app component and the assigned developer does not possess the required skills to do both.
• Understand and document the exit conditions to a story. For example “Cannot create user name that is less than 6 characters,” or “Password must be verified,” or “Uses CAPTCHA to ensure human input.” Exit conditions can later be used to formulate test cases for the QA department.
• Use the general understanding of your team’s skill level to determine the estimate. For example, How long would an intermediate frontend developer take to do this? (versus a junior developer)
• Remember that all chores and exit conditions required to complete any story should be accounted for in your points estimate. “Chores” relate to completing user stories but are more specific to developer tasks. You do not need to use story format for writing them as they are used internally — i.e. “Set up user database table” is fine as a chore.
• If your estimate for any single story is greater than 4 points (two days’ work) it means the story is too big and needs to be broken down into two stories, or more, until no single resource has an estimate of more than 4 points per story. For example, the story “I can manage users” could be separated into “I can add a user” and “I can edit a user’s details,” and so on.

Step 4 — Calculate the total number of points on the project overall

Calculate the total number of project hours by multiplying the total points per story. This is when you know how much time the project will take to complete.

If you bill different rates for developer skill levels, you can also break out these hours by multiplying the total points per resource.

Step 5 — Compare all of your calculations against the project budget

Compare all of your calculations to the final project budget and previous estimations and seek to ensure they are 30% or more below. This margin accounts for addressing bugs, unforeseen activities or tasks, deployments, and project management time.

If the calculated time is not within the originally allotted budget, reconsider all aspects of your estimate.

Are there ways that you could bring the estimate down?

Could a different approach / architecture be employed to make it work?

Could different resources be assigned to complete work in less time or at a lower cost per hour?

If you are unable to refactor the work within the bounds of the SOW (i.e. using outlined requirements / systems / infrastructure), it’s a good idea to document all of your findings and call a review meeting with all relevant project stakeholders.

The goal of initial estimation is to have a clear path for moving forward on the project. If expectations need to be adjusted, so be it. In our experience it’s better to adjust expectations at the outset than fight for justification later when bearing down a deadline. Remember, when it comes to excuses, one is as good as another.

Transferring Stories (into Pivotal Tracker)

Once the initial estimate is complete and final, transfer all user stories and chores into Pivotal.

• Create epics first and assign appropriate tags to them. Tags should be simple and clear, such as “frontend” or “user-management.”
• Log stories sequentially by feature set, ensuring each contains the appropriate sub-tasks and exit conditions for delivery. Tagging stories will automatically link them to their related epics (in Pivotal you can only have one unique tag per epic). Put everything into the “icebox” first.
• Assign the appropriate estimate, in points, to each story by adding up all of the points you previously estimated for each resource. For example, if you have a story of “I can manage users” that will involve a frontend and backend developer, each with 2 points, the total of the story should be 4 points.
• Remember to also create any required chores you have outlined. Chores should be linked to the appropriate epics (through tagging), and inserted nearby related user stories.
• Create “releases” in Pivotal that match the dates of all previously agreed-to milestones and preview builds (in the SOW). Then pull all the stories out of the icebox that relate to each milestone and match them with the scheduled releases so that the developer team can start the work in the order of priority that was set by client and / or accounts.
• Pivotal will automatically alert you if a scheduled milestone is not achievable based on the velocity of the project. The initial velocity of any project is 10 points per week and then Pivotal will automatically adjust it based on actual velocity (i.e. how quickly work gets “delivered”). You can override the velocity to see the preferred outcome, but it’s best practice to let Pivotal reflect reality rather than force unrealistic timing. From herein, delays can be monitored proactively by the project management team.

Maintaining the Project

This initial setup starts the project on the right foot, but it’s only half the battle. Equally important is the constant maintenance of stories and chores within Pivotal so that a realistic, real-time understanding of project effort (and delays) is always available.

Some important things to keep in mind:

• Story estimates can change mid-stream. For example, once a developer finishes a story they may realize that subsequent related stories will be much easier, or harder, to do. Pending stories should be adjusted immediately to reflect new insights.
• Change is part of any project, and that’s ok. Having things organized from the start will make it that much easier to account for change. Affected stories should have their points estimations updated. New features or requests can be estimated and inserted as desired. This is a really great way to measure the impact that new requests or change orders have on planned timelines.
• Do not log bugs as new stories. This will distort your project velocity data. If bugs emerge through testing, handle them either by rejecting the ticket altogether or by creating a “bug” ticket in Pivotal (which does not require points estimation). Equally, remember that an improvement is not a bug but rather a newly defined condition. Improvements should be created as new stories and estimated accordingly.
• Constantly review status with your developers. Daily meetings are a good idea — a quick 15 minutes can go a long way to ensure that everyone is on the same page. It also ensures that stories and estimates are always up to date and significantly reduces overall project management time. A lengthier weekly meeting, at the start of the week also lets you plan out the week’s activities together. Having standup meetings with the client after this weekly meeting is a great way to keep the client up to date.

Estimating Points

Here is how we define and estimate points at The Development Factory.

• 0 points: Any story that requires less than 1 hour of work should be estimated as 0 points. Ideally these stories should be lined up alongside like components or rolled up into a more complete story — i.e. there shouldn’t be a lot of 0 point stories in any project.
• 1 point: Any story that roughly requires 1 to 4 hours of work. As with 0 point stories these should ideally be rolled up or limited (unless the project is quite small or simple). After a project begins it’s likely that more 1 point stories will come up. This is ok, as usually they pertain to edge cases or grey areas that were not documented or thought of at the outset.
• 2 points: Any story that roughly requires 4 to 8 hours of work (1 day).
• 3 points: Any story that roughly requires 8 to 12 hours of work (1 and a half days).
• 4 points: Any story that roughly requires 12 to 16 hours of work (2 days).

Remember that the story estimate is a cumulative calculation of the time required by all developers working on the story. Because there should never be more than three developers per story or more than 4 points per developer the maximum points for any individual story is 12.

Supporting Processes

There are several ancillary processes that do not relate to Creating Epics and User Stories, but are helpful to create and document for effective project management.

They are:

• Project Initialization Process — the project manager’s process for initializing and organizing a new project (which includes interacting with Pivotal as well)
• Project Maintenance Process — managing the project through its lifecycle, and addressing change in estimation and scope (see above)
• Quality Assurance of Web Solutions Process — QA of solutions performed inline (and at the end of) projects
• Quality Assurance of Mobile Applications Process — QA of solutions that are built specifically for any number of mobile platforms, i.e. not web-based (but not necessarily native either)
• Code Review Process — quality, logic and syntax review of submitted code based on feature branches that relate to stories
• Team Planning Process — resourcing and time allocation for the project

These processes are covered at length in other chapters of the book.

written by @suzanneabate and @andrewbodis for The Development Factory.

This read is an advance chapter from the forthcoming book How to Build a Digital Department: Practical Steps for Insourcing Web Development.