PROJECT PLANNING AT ACRO

Strategy: Project Backlog

The final segment of this series on our Discovery & Strategy focuses on bringing all the work we did in the previous phases to build the project backlog or the body of work we need to do to reach a client’s goal. Anders walks us through this critical process.

Transcript

Hi, I’m Anders Paulsen, Director of User Experience at Acro Commerce.

In this final chapter of our Project Planning series, we’ll cover the project backlog.

In our previous videos, we covered our Discovery and Strategy phases, including the exercises and deliverables used to inform a strategy for development. We also looked at how our team captures project requirements as stories from the IA, TA, and Prototype, which are collected in a project backlog as issues representing the project’s scope of work.

Next, we’ll identify priorities within the scope of work and order the backlog with the highest priority issues at the top of the list.

In development, issues will be pulled into time-boxed sprints, starting from the top of the backlog. Sprints follow a consistent cadence and include regular demos to ensure visibility and continued feedback right up to launch.

But our first step is to Import our stories into Jira, our issue tracking system. Each Story becomes an issue within the backlog.

Let’s take a closer look at our common issue structure. To start, we have the standard user story format of “As a Who I want to What so that Why,” or the standard System Story format of “Action the subject so that objective.”

Now, to more easily identify our ticket, we want to give it a clear, concise Issue title. In Jira, this field is referred to as a Summary.

Next, the team’s architect, designer and PO (product owner) will add further details and recommendations. UX direction outlines design recommendations, feature requirements, as well as expected functionality and interactions. This may include visual references, such as mockups or prototype links. The technical direction outlines development recommendations, implementation requirements, and an overview of the expected features and functionality. This may also include links to technical documentation and other references.

With UX and technical direction accounted for, a list of acceptance criteria will be compiled to provide a checklist that can help guide the review and testing of completed work.

At this point, the team should have all they need to provide a couple of estimates. The first, is business value, estimating the overall benefit a feature is expected to bring to the project as a whole. The second, estimates the level of effort required to complete the feature, measured using story points.

Based on the Fibonacci sequence, story points follow a pattern of one, two, three, five, eight. These values provide our range of issue sizes, based on a relative estimate of effort required to complete an issue, rather than getting hung up on quoting hours. A thirteen represents a story that is too large and should be broken down into multiple smaller stories.

With these details accounted for, we’re ready to begin identifying priorities. By reviewing the story point value of each issue, along with its business value, we can prioritize issues providing the highest value and requiring the lowest effort first. Meanwhile, stories determined to bring low value and require high effort should be considered the lowest priority and potentially reconsidered or even removed.

Within the backlog, we’ll continue to review and reorder issues based on the priorities we’ve just established. We’ll also organize related stories further into categories known as epics. Epics allow us to take a step back and view the project as a whole. From this high-level perspective, we’ll separate epics into a few key phases.

First, we’ll pull forward the most essential requirements for starting development — the work necessary to produce a minimum viable product. With an MVP we’ll establish the necessary structure and connections to demo working code that displays the ability to meet project requirements.

Often this includes things like setting up the design system and page structure, connecting to a content management system and configuring menus, ensuring we’re able to retrieve content types by setting up the necessary API connections, and potentially connecting to an ecommerce platform or CRM (Customer Relationship Manager).

Next, we’ll continue development to create a product that’s go-to-market ready. We’ll work with you to identify your absolute requirements for the site launch. It’s important to identify which features are truly ‘must-haves’ in order to ensure that lower-priority tickets won’t delay launch. Once we’ve achieved that ‘GTM’ milestone, we can always continue to develop those ‘nice-to-have’ features post-launch, but with the advantage of beginning to collect data from real site users, we can also continue to make refinements and test new features from sprint to sprint.

That’s why we refer to this next phase as Optimize. While our list of optimizations may start out as lower-priority ‘nice-to-haves’ from the original backlog, you’ll likely find that by testing and collecting feedback from the interactions of real site users, we’ll identify new opportunities to explore that will truly enhance the experience of your customers. At this point, adding to the backlog is encouraged, and adjusting priorities is welcome and to be expected.

Now, a quick recap of the backlog structure.

Our initial development epics are grouped into MVP and Go-to-Market (GTM) phases.

Each epic contains a collection of stories, which include estimates of business value and story points indicating effort based on the acceptance criteria listed in the Issue. These estimates inform the order in which issues are prioritized for development.

As a selection of stories is pulled into an upcoming sprint, the developers will break down the scope of work into individual tasks for completion, referencing the acceptance criteria on the related story to ensure requirements have been met. The team pulls issues prioritized at the top of the backlog into the scope of work planned for each new sprint, presenting work completed at the end of the sprint.

This sprint cycle is followed throughout the project, so the PO works to ensure the backlog continues to reflect priorities through to launch.

From there, we’ll continue to refine and optimize the site from sprint to sprint — If you decide to adjust priorities, we can accommodate. If you’d like to add a New Feature, that’s encouraged. Want to prioritize that new feature? Not a problem. That’s the whole purpose of the Agile approach.

Thanks again for listening. I’m Anders Paulsen, at Acro Commerce.

If you’d like to learn more about Agile Project Development, check out our video series Agile at Acro.