Scoping the work

Stories / Features

I will be calling stories "features" in this section. This better illustrates how to organize work into logical pieces.

Definition: What is a feature?

A feature is a small set of changes that build up to solving a particular problem for a stakeholder.

Breaking down into features

If we were building an authentication service, the features may break down to look like this:

Good: Provides incremental value

• Title: "Customers have the ability to log in"
  • "When I go enter a username and password that is correct, I am logged in"
  • "When I go enter a username and password that is incorrect, I see an error saying 'invalid username or password'"
  • "When skip entering a username or password, I see an error saying fields are required"
• Title: "Already logged in customers cannot visit login page"
• Title: "Customers are logged out after 24 hours of inactivity"
• Title: "Customers can manually log out"
• Title: "Employees are able to log in as customers"

Each of these stories delivers a small amount of value to the larger project. Each feature stands on its own, meaning it provides value without being dependent on another.

Let's talk through some popular alternative ways to scope features:

Bad: Features are too big

In this scenario you may have just two features:

1. "Customers can authenticate"
   • "Customers can log in"
     • "When I go enter a username and password that is correct, I am logged in"
     • "When I go enter a username and password that is incorrect, I see an error saying 'invalid username or password'"
     • "When skip entering a username or password, I see an error saying fields are required"
   • "Customers can log out"
   • "Customers are logged out after 24 hours"
   • …
2. "Employees can log in"
   • "Employees are able to log in as customers"
   • …

Issues

1. The tickets are too long and folks skip over them.
2. They cover far too much surface area to be held in your brain.
3. It is unclear what parts of the story are essential, nice-to-have, or optional.
4. Testing every scenario is difficult as there is just so much to test.
   • Smell: You need a matrix for every user scenario as part of the ticket.
5. Too much needs to be built to show progress.
   • Smell: The story will stall in "In Progress" for a long enough time, folks will ask for an update in stand-ups.

Bad: Features that are just task lists

• "Create login page"
• "Connect login page to Auth Service"
• "Add cancel button to go back to home page"
• "Guard login page from logged-in users"
• "Detect when customers inactive for 24 hours"
• "Log out inactive customers are 24 hours via CRON"

Issues

1. Difficult to track progress: When can a user log in? When can they log out?
   • Smell: Folks will want updates to "explain what this means" in the form of stand-ups or written updates.
2. Difficult to know when "done means done", when do we QA everything?
   • Smell: Do you have a QA ticket?
3. Any adjustment in implementation requires updating all tickets.
   • Smell: Tickets say "Blocked by other ticket"
   • Smell: Deliverables say "X will be done as part of other ticket"
4. Stories must be worked in order.
   • Smell: Engineer asks what to pick up next when the backlog is not empty. Their response is "I can't until […]"
5. Engineering implementation is hiding product value
   • Smell: Engineers cannot answer "Why is this important to the business?" on their own tickets. Their reasoning is coming from describing the implementation like "Without log out, we cannot test log in".

What goes into a feature?

A good story has clear answers to the following questions:

1. What problem are we trying to solve for the business?
2. How will we know when we solve the problem?
3. What makes solving this problem worth solving?

Exercise: 10 seconds to find your why

Are you not sure why a story needs to get done? Hover over the delete button. Give yourself to the count of 10 to come up with a reason why you need to do this or delete it. As you get closer to zero, panic sets in, and you're primed to blurt out your answer: "Times up!" - "Wait! Without this though we'll have no way to ever log someone out!" – There you go, that's why you need to do this work.

Exercise: How to know when it's done

The feature is "Allow a user to log out manually". How do we come up with a complete list of deliverables?

Imagine you are going to pay a total stranger to verify this problem was solved. You didn't get to speak to them, they just had the ticket in front of them. What would you put as acceptance criteria assuming this person knew nothing of the implementation or systems?

Would you write:

• The authentication service destroys the cookie successfully after logging out
• Emit data to the security team's audit log.

OR would you write:

• After hitting the banner in the top of the landing page (https:…), I see a red banner like this (see Login Screenshot below).
• When logged out I can see the Login button
• When logged in I cannot see the Login button
• After logging out, when I visit the Security Team dashboard (https:…), I can identify an entry saying my user is now logged out.
• After logging out, restarting my browser does not log me back in.

By using the latter format, you have a stable idea of what it takes to solve the problem. If the banner is missing, the user won't know they are logged out, we need to reject the feature and keep working on it. It is also implementation independent. This means an engineer can make optimizations to their implementation as they see fit. These optimizations do not change the outcome of the feature. They only solve the problem in a better way.

Commonly missed deliverables

• Notify a person or team about the change ahead of release.
• Get sign-off from someone before merging.
• Write public-facing documentation for this new feature.
• Draft a new feature in the icebox to perform a follow-up action.

These all go into "done means done", but are often omitted. Acceptance Criteria is what it takes to get something done and that usually includes some organizational pieces. Do yourself a favor and capture them.

Exercise: Mapping a problem to the business

Sticking with our feature "Allow a user to log out manually". We've already discussed why we need this, "Without this we'll have no way to ever log someone out!", but what is the problem this solves for the business? Often you can ask "What value is added by solving this problem?"

Some ideas might be:

• "Provide a way to safely access our site from a public computer"
• "Provide a way to switch user accounts"

This is intentionally a trivial example. It illustrates that even the most trivial or the most engineering-specific feature requests can map to a problem and potential ROI (return on investment).

A secondary benefit to this exercise is you've made your request generic. You've distilled an ideal specific implementation into a problem statement. This opens the feature up to alternative designs that solve the same problem. This problem can now utilize the collective intelligence of the engineers building the feature. If they have experience solving this problem in a better way, they know they can pitch it because they know the problem you want to solve.

Adding additional context to a story

When planning with your team there may be suggestions from teammates about how to approach the problem or a pro-tip that can clarify where to start. These remarks are not part of the What, Why, or Acceptance Criteria. Where do we put it then?

I suggest adding a "Developer Notes" section in a smaller heading size at the bottom of the ticket. In this section, put any suggestions or context that will be helpful to whomever picks up the ticket. After the story is completed, I will often delete this section completely. This section is information for the implementor to take as a suggestion, they either did or they didn't. After the story is delivered whether they followed the advice or not is moot.

Handling technical debt

I'll keep this section short. As you are working through a queue of work, leave the codebase a little better than you found it.

Stepping over technical debt is just a bad idea.

Stopping everything to tackle technical debt until it's gone is just as bad.

As you work on features, if you come into some technical debt, give yourself a timebox to make it 1% better.

Cannot iterate on tech debt

If you are hitting technical debt that you cannot make 1% better, you likely need to spend the time to raise the quality bar on code reviews. Technical Debt that cannot be iteratively improved upon is rare. If every engineer makes the code 1% better each time they touch it, bad decisions or code gets corrected very quickly.

What's a bug versus a feature?

Some systems call "bugs" a "defect" to reinforce this concept. A defect is something that was intended to have been built in a feature, but was missed. A bug is not acceptance criteria that was forgotten. Forgetting acceptance criteria should be treated as a new feature to add that new functionality.

It's not worth going back-and-forth over "feature vs bug" as the work is the same, but this section was added here for completeness.

Chores: Handling research tasks

I get this question all the time, "Oh so Chores are like Spikes.". Wrong.

A chore is a special kind of story that is intended to drive one or more new feature tickets. As an example lets stick with our login system feature. If I was writing those features and I couldn't write anything but TODO or TBD in various sections, I need to start with a Chore. That Chore would be something like this:

## What
In order to design a login system, we need to research how
these systems are commonly built.

## Why
Login systems are a common UX pattern that users can be very
confused with as-is. If our system does not match our competitors, it
will cause more confusion and likely more support requests which costs
us a bunch of money.

## Acceptance Criteria

- Compare login flows for Acme Co & Beta Inc
- Draft a recommendation on which system we should mirror highlighting
  the reasons.
- Break down recommended solution into new feature tickets linked to
  this one.

This ticket can now be worked on. It matches the format of a feature ticket, it has a What, Why, and Acceptance Criteria. Why is it not a feature? Well doing this ticket does not provide measured impact on the business (no ROI, but drives future potential ROI).

Estimation

Estimation is a tool used by engineers to set delivery expectations, it is not something directly relevant to product. If you're team is able to set and hit a delivery date without estimation, you can opt out of doing traditional agile estimates.

Estimates like Fibonacci and T-Shirt sizing are for engineering only. Sharing "Well this will take longer because they are 4 XL tickets" with product isn't the correct way to communicate with product. The correct way to communicate this is "This will take longer as the complexity with this task isn't something our team is too familiar with." Why change the phrasing? There are a variety of reasons your team may have arrived at XL for a given story. When communicating with product, that should be translated from story-point into an expectation.

Some common reasons for large story sizing:

• The team lacks experience in the problem-space, so we're hedging against that risk.
• External dependencies, such as other teams input, that we cannot derisk any more than we already have.

Remember that estimation is a tool that sets a deadline. Give yourself and your team ample time to deliver. Make sure if someone is sick, the team can absorb the inconvenience and still deliver on time.

NOTE: Giving extra time for unexpected things also releases stress from the team. It keeps them further away from burnout as they know a hiccup isn't going to risk the entire project.