How to Ditch User Stories and Backlogs to Create Better Alignment

Nishal Narechania April 4 2022

Since late 2020, I have served as the VP of Product at Territory. We connect thousands of customers to great-tasting healthy meals that fit their needs using proprietary recommendations and menu optimization powered by machine learning. Six months ago we ditched the traditional backlog filled with user stories.We stopped focusing on story points. We don’t use burndown charts to gauge how on-track we are or are not. Why? We believed these scrum concepts focused on the wrong things. 

At Territory, user stories and backlogs were esoteric. They were not written in plain language. PMs usually wrote them alone, in a silo. Designers didn’t create designs based on individual user stories. Engineers didn’t use stories to plan their work. We ended up with a backlog where 80% of the stories never made it into a sprint. 

The other big issue was a focus on outputs that don’t matter: story point velocity and burndown charts. The PM and engineering team were tracking progress against an arbitrary number of points in a given sprint.

We corrected these two issues by changing how we plan and execute product work. First, we implemented a new process around solution alignment. Second, we created goal-based sprints. These two changes refocused our work and led to a better product.

How Territory ditched user stories and backlogs

Problem and Solution Alignment Framework

Territory adopted the solution alignment process used at Figma to help empowered teams structure and define product initiatives. Our solution alignment process was centered around what we called a Product Brief. The product brief contained three primary sections: 

  1. Problem alignment
  2. Solution alignment
  3. Launch readiness. 

The product brief was a living document that was updated and referenced as more information became available.

Territory created empowered product teams. An empowered team is given the freedom to determine the most important problems to solve to help customers achieve something important. The team pulled together three individuals: product manager, designer, and engineering lead. This team drove all problem and solution alignment activity at Territory.

Problem alignment

In this section of the brief we define the problem identified by the PM. We describe a very high level approach to the problem - how would Territory go about identifying the solution. The high level approach is fleshed out by the PM with input from designers and engineers. We finished this section by writing down our initiative goals and success criteria. Let’s double-click into each of these sections.

Problem definition

We defined specific problems that need to be solved for the customer. Territory used customer feedback, customer interviews, and market research for most problem definitions. We also noted what problems we would not solve with the proposed solution.

High-level approach 

Second, we described our high-level approach to the problem. The intent is to provide enough information for the reader to imagine possible solutions. This section begins to introduce ways in which the problem can be solved. For example, if a certain email notification is not being seen by all customers and possible approach would be to explore and test new channels such as SMS. 

Goals & success criteria

Finally, we defined our success criteria. We defined which business or product metrics showed our progress toward addressing the defined problem. This is an initiative level goal and is likely achieved by releasing a number of features.

Solution alignment

This is the meat of the brief. In this section we start to flesh out what our solution would be to solve the stated problem. This started with defining the key features. Features are the things we need to change in the product to solve the problem. Second, we documented the key user flows of the solution. Finally, we kept a running list of questions and key decisions. One final note before going into the nitty-gritty of each section: The sections were not always filled out sequentially. The order below is how the Solution Alignment section of the brief is structured. Let’s take a look at each in detail.

Key features 

We documented the features of our solution. We categorized them as must have, nice to have, and won’t do similar to MoSCoW. This section is the closest our team came to writing user stories. Instead of using the esoteric story format we documented our features in plain language that was easy to understand. We also kept the feature descriptions high-level, giving the engineering team maximum flexibility in building out their implementation plan. PMs led this part of the document with input from designers and engineers.

Key flows 

We included how the solution should flow for the customer. Designers led this process. This part of the brief was always a living document. For this reason, Territory always linked out to our designs that were done in Figma. This ensured the reader of the document would always see the most up-to-date design and flow. The key flow was a major input into the implementation plan as it conveyed the logic and design needed to carry a customer through the solution.

Questions and key decisions

With every solution there were open questions and unmade decisions. In the true spirit of agile, we would iteratively answer questions and then document the decision. This running record always comes in handy down the road when we need to answer questions about why a certain feature works the way it does. Like key flows, this part of the document was living and updated as new questions arose and decisions were made.

Launch readiness

This section was very tactical. First, we provided a high level launch plan with key milestones. Then, we detailed the cross-departmental activities that were required to launch new features. This section was usually populated last and once most key questions and decisions were set in solution alignment.

Key milestones 

Just as the title implies, we documented key feature milestones and an estimated timeline for delivery. We always treated deadlines as a probability distribution of when the feature would launch. In other words, the dates were always estimated and updated as needed. At Territory, we would gradually release features to our customers to ensure quality. We would start with 10-20% and then set two week milestones to get to 100%. In each increase we actively monitored key product analytics and customer feedback channels to determine if features worked as expected.

Launch checklist

For every feature we documented the cross-department communications required to launch a new product. This usually entailed coordinating with marketing, operations, and customer support teams. For each stakeholder, we documented what activities and communications needed to be completed before executing on our milestones. Territory would create a list of questions with Yes/No answers. When an answer was yes, we documented instructions on what action must be completed prior to launch and with whom. For example: 

  • Question: Do we need to train our customer service team on how the new feature will work?
  • Answer: Yes
  • Instructions: Set up training session pre-launch to walk CS leaders through new features being delivered and ensure they have all necessary information to service customers once features are released

Solution Alignment Sessions

Territory instituted a weekly session to drive the solution alignment process. This touchpoint between product managers, designers, and engineering leads was a critical collaboration point. The agenda was structured to elicit healthy discussion and argument about the path forward. 

This is the agenda used at Territory:

  1. Product manager presented a draft product brief to the engineering lead and product designer
  2. The team reviewed problem alignment and solution alignment sections to ensure everyone had the same understanding of problem statement, approach, success criteria, and key features
  3. The team documented action items and next steps to complete fleshing out the key user flows and technical implementation plan

Implementation Plans

Once problem and solution alignment was completed the final step was creating an implementation plan. This activity was led by the engineering lead. Implementation plans replaced the traditional scrum backlog of user stories. The implementation plan included a high level technical approach to delivering the solution. The engineering lead worked with the larger product engineering team to refine and plan out work across one or more sprints of work. 

Goal-Based Sprints

The second innovation Territory added to its product approach was a rethought agile delivery model. Traditional scrum processes focused on a number of standard ceremonies. We kept several of these ceremonies, but adapted them to support our problem and solution alignment process. 

Refining implementation plans

As we covered previously, the engineering lead led the creation of an implementation plan. This is the first step of turning a solution into a digital product or feature. Our engineering leads would hold refinement sessions with the engineering team, PM, and designer to review implementation plans. During refinement the engineering team was presented the product brief by the PM and designer. Then the implementation plan was reviewed and the team started to break down the plan into specific engineering tasks. Engineering tasks ultimately created the body of work the engineering team would complete over one or more sprints. This process created a well-understood path forward for building the things needed to solve the problem. Our teams worked in an agile environment. As tasks were completed they were released and tested. If the tasks were part of a larger feature we implemented feature flags to control when the feature would be customer facing while enabling larger integration testing. We used an experimental approach to releases, typically launching to a portion of our customer-base to production test the feature.

Planning goal-based sprints

Traditional scrum teams hold planning sessions at the start of a sprint. They would review the prioritized user stories and story points and make a commitment to the number of points they wanted to pull into a sprint. This approach created a hyperfocus on story points. Instead, Territory dropped the notion of user stories and points altogether. Instead, the engineering team would shift focus to achieving one or more goals in a sprint. Here is a real example from a prior planning session:

  • Launch the new meal details page to complete our initial rebranding efforts and prove the platform system design and infrastructure
  • Start to build the checkout frontend and integration with the existing system

While these goals are still somewhat aligned to output, the team rallied around these goals. These outputs tied directly back to the problem and solution alignment the empowered team created to build our new ecommerce platform.

Implementation plans often spanned more than one sprint. Using sprint goals our engineering leads were able to break down each implementation plan into smaller, achievable, pieces. This approach did temporarily limit the predictability of when something would be delivered. Product and engineering executives worked with business stakeholders to build up a level of trust that the work would be complete in time to support Territory’s business strategy.  As the team completed sprints, we were able to calibrate their delivery cadence and return to better delivery forecasting. This allowed us to bring greater clarity to when features would be available to the rest of the business.

How to Implement This System at Your Company

Assemble the right team

Pulling together the right team is the first step to implementing this process. As we reviewed in the previous sections - the people on the team fill crucial roles. The product manager needs to have solid product discovery skills. They need to tease out the friction points and problem areas the customer feels. The designer needs to translate solutions into a usable experience. The engineering lead needs to keep the solution grounded in feasibility and help the engineering team break down solutions into implementation plans. Finding skilled people to round out the empowered product team is really important.

Start small

If there are multiple product teams you have a distinct advantage: You can start small. Have one team shift to solution alignment and goal-based sprint commitments. This will allow you to work out any kinks and further adapt the approach to your organization. Like scrum, this approach is not a one-size-fits-all. Once you are happy with a process and have successfully delivered on one or two solutions, expand the approach to the rest of the product delivery organization.

Share the approach with the whole company

Like most things, this approach works best if all stakeholders are bought in and understand how it works. Stakeholders, when appropriate, would also participate in our solutioning process. Every feature we build needs to also work for the business.  At Territory, we frequently share our process with new hires and those who need a refresher. This enables stakeholders to participate in the product discovery process - uncovering problems that need to be solved. 

Closing Thoughts

Figuring out a user-centric system that works for your team isn't easy. If you're looking to optimize your product development process and focus on creating cross-functional alignment on what to build? Contact us to discuss how we can help.


Written by Nishal Narechania

Nishal is a Product Advisor / Coach at Prodify. Currently, he serves as the VP of Product at Territory.

Get New Content