Who tests what criteria for epics?

Question

So our product owner is in a position where she feels encumbered by the decomposition of a large user story:

1. Product owner presents a story
2. Engineers determine that it is too big for a single story
3. Engineers convert it to an epic (or theme) and then write additional user stories (as developers) that we need to complete the epic.

Rather than have the PO write the developer [sub]stories, we write them for ourselves with the understanding that when all of our stories are complete, we will deliver the epic and the acceptance/confirmation will be done on criteria originally written by the PO (the original story that we converted to an epic)

• PO's Story (as a admin, I want to blabbity-blah, so that I can blabbity blah) (total 21 points)
  • Dev Story 1 (8 points)
    • Dev Story, Task 1
    • Dev Story, Task 2
  • Dev Story 2 (13 points)
    • Dev Story, Task 1
    • Dev Story, Task 2
    • etc...

And so on...

This is easier for the PO to manage. She just writes up the story, so she can remain high level with her eye on the bigger picture instead of wasting hours writing additional stories that she has no interest in nor does she understand. The devs are happy because we can break everything up into logical workloads and point them, then task those out to provide a WBS.

Now, the engineering manager is a bit uneasy because he wants each of the dev stories to be tested against some sort of acceptance critieria int the same way the Epic Story will be accepted/tested; as milestones/checkpoints so to speak. We are recommending something more low level in these instances: for instance unit test suites that show everything is passing, and/or QA running SOAPUI tests against new webservices, or other test tools -- but mainly unit test suites for things that don't yet have a front end.

So in short, we're recommending that dev stories are accepted by QA through the results of different kinds of tests. We'll try to keep QA involved with the requirements so they can ask questions during the process and ensure that engineers are keeping the original acceptance criteria in sight. Then we'll have the PO and QA do acceptance on the original story once the Epic is delivered and that will be done against the critieria written on the original story which we converted to an Epic.

So my question is: do you see anything intrinsically wrong with this? How do you approach the testing of epic, etc?

Answer 1

Make an effort to write independent smaller stories

...additional stories that she has no interest in nor does she understand.

Don't write stories that the PO doesn't understand. If it is for developers' convenience, it is not a story. It is just a technical task. Put in more effort in writing smaller stories that the PO does understand. See previous discussion in PMSE here how to split larger stories.

By the way, it is not that the Product Owner toils alone to write stories and acceptance criteria. In backlog refinement meetings, the development team should collaborate with the Product Owner to split the stories and write acceptance criteria.

...unit test suites for things that don't yet have a front end.

Unit tests are for developer productivity. They can reduce the amount of regression testing to be done by the QA team. However, they are no substitutes for QA and PO doing acceptance tests from the end-user point of view. Stories should be vertical slices (with a front-end and a matching back-end).

So my question is: do you see anything intrinsically wrong with this?

Yes. Your team seems to be burdened by waterfall thinking. This is not unusual for teams trying to transition from waterfall to agile. Try to get some help (using online resources or a mentor) with slicing stories vertically. Your Engineering Manager seems to have the right instincts. That is a huge positive!

How do you approach the testing of epic, etc?

You don't. The team should put in the effort to write independent smaller stories that the PO can understand and test.

Answer 2

TL;DR

Who tests what criteria for epics?

Epics and themes aren't generally testable, so the answer is really "no one." Instead, the entire Scrum Team must decompose these too-large items during Backlog Refinement or Sprint Planning until they are stories that contain testable criteria that can be measured.

The entire Scrum Team, which explicitly includes the Product Owner, must collaborate on defining actionable user stories that are testable and demonstrable. Your current process does not encourage sufficient collaboration to make this happen.

In addition, your current process causes the team to miss out on opportunities to collaborate with the Product Owner to negotiate implementation details that add value, reduce project costs, or lead to increased sustainability. While the Product Owner shouldn't have to care about code-level details, understanding the trade-offs involved in different implementations can help the whole team to ensure that the right thing is built, and that opportunities to build a potentially-shippable increment are increased through open discussions about Minimum Viable Features and YAGNI principles.

Epics and themes should never, ever make it off the Product Backlog and into the Sprint Backlog. Doing so is a very strong "project smell" that indicates a fundamental problem with the implementation of the team's Scrum process.

Tasks vs. Dependent Stories

Stories

Stories and tasks are two different things. A user story has a format that's expected to act as a placeholder that defines a feature, a point of view representing the beneficiary of the feature, and a context. Variations of the Connextra format is what people think of most often:

As a [role or "value consumer"],
I want [feature or functionality]
so that [benefit within some context].

A story is a conversational placeholder to enable collaboration, and isn't intended as a full-fledged specification. Stories are generally estimated in story points (e.g. modified Fibonacci sequence, tee-shirt sizes, etc.).

Stories generally live on the Product Backlog, because while they adhere to the INVEST mnemonic they represent value to the project and potentially-shippable features.

Tasks

On the other hand, a task is a checklist item that helps them team track their progress towards story completion. A story should have tasks, but a story should (as a rule of thumb) not have dependent stories.

Tasks often live on the Sprint Backlog, rather than the Product Backlog, because they are really implementation details or technical milestones rather than stories that should strictly adhere to the INVEST critiera. Nevertheless, they should be small and testable, so there is certainly a bit of overlap.

Tasks can be story-pointed, but are often estimated in ideal hours rather than levels of effort. For example, a story like:

As a banking customer
I want to be able to use any ATM without fees
so that I have ready access to my money at any location.

should be broken down into discrete, measurable tasks during Sprint Planning. The tasks for this story, whether they are on the back of a story card, items on the Sprint Backlog, rows on a spreadsheet, or contained on their own index cards, might look like this:

• ☑ Add a database column to track ATM network membership. (2 hours)
• ☑ Add a database column to track fees associated with foreign-network ATM withdrawals. (16 hours)
• ☐ Add model callbacks to reimburse customers for ATM fees attributable to withdrawals at foreign ATMs. (8 hours)

Tasks can be added, deleted, or modified by the team throughout the Sprint as things are learned, or as dependencies or implementation details are discovered. The Sprint Backlog belongs to the Development Team, not the Product Owner, so the contents of the team's backlog reflects the work that the Development Team needs to do to implement the user story from the Product Backlog.

Collaboration

While the Product Backlog belongs to the Product Owner, and the Sprint Backlog belongs to the team, it is nevertheless useful to ensure that both artifacts are visible to everyone in the organization in order to foster collaboration.

A Product Owner who can't see the level of effort or hours involved in story-related tasks has insufficient visibility into the real costs of a given story, and the team loses out on valuable opportunities to collaborate on implementation details that are negotiable. For example, during a Sprint it may turn out that the Product Owner doesn't all fees for all banks covered; the 80/20 rule means that perhaps the team can concentrate on hard-coding values for three local banks that generate the most complaints, rather than having to engineer a more flexible solution that would apply to all banks everywhere.

Unit/Feature Testing and Sprint Review Demonstrations

Epics aren't testable or (generally) demonstrable. Neither are themes. That makes them unsuitable for Sprints; they should only be used for long-range planning, and decomposed as needed during Backlog Refinement or Sprint Planning.

All stories that adhere to the INVEST criteria are inherently testable. In my personal experience, stories should generally be driven by feature or integration tests, and tasks should be driven by unit tests. There are certainly all kinds of caveats and exceptions to this rule of thumb, but following this advice helps in many ways, including:

1. Feature tests (such as automated browser testing) show the feature from a user-visible point of view, and may even stand in for user acceptance testing in many situations.
2. Feature tests build trust with stakeholders, and often demonstrate that the Right Thing™ was built.
3. Unit tests are for the Development Team, and help drive design and prevent regressions. They are generally uninteresting as Sprint Review demonstrations, but are the most important items from a sustainable development point of view.

4. This style splitting TDD and ATDD along the lines of features vs. tasks helps maintain the testing pyramid, with a few slow high-level tests supported by a base layer of blazingly-fast unit tests. For example:

   

As always, there will be exceptions and caveats, but as rules of thumb I have found the foregoing to be reasonably solid practices. YMMV.

Answer 3

A Shorter answer than the other Epics:

Yes there are problems with this approach. While it works as long as everyone is happy, The risk is lost of detail in the requirements.

If your overall solution has become so complicated that 'simple' (as considered by PO) changes are considered 'epics' by the engineers, the PO will not understand the impact of changes and/or delays and the engineers may not implement with the PO 'really wants'

I think its a legitimate challenge to agile methodologies to ask how to handle these bigger multi-layered systems, where for whatever reason small changes to what the user sees can entail large changes 'behind the scenes' in service layers/databases etc. The thin slice approach of delivering discreet functionality can in fact push you into this position, where instead of a requirement for a generic flexible interface for a lower tier you can end up with a multitude of inflexible mini interfaces.

I would you counter this problem by writing a meta requirement/story for your lower tiers to get that flexibility back in and support 'simple' changes to user functionality without requiring change to base functionality.

Your lower tiers may even need splitting off into their own product with their own PO