3

I'm a developer. We have a non-technical BA writing our stories. There are a few stories coming down the pipeline that have a small business description. These stories require an unusually large amount of technical design and work. We do not want our non-technical BA writing up a bunch of technical detail. We also do not want a single story that consumes 3 sprints of effort.

Contrived example story

"As a user I need to identify our top paying clients so that I can send them a gift"

The technical design of this feature is complex. It's ~3 sprints of work. If we break it down then it will turn into a bunch of technical tasks.

Please note this is a contrived example. Roughly, the complexity of implementing this story involves writing complex analytical algorithms to aggregate the necessary data, writing several new API's to support the need, and calling into disparate legacy systems...in other words a bunch of technical this and that.

How can we resolve this kind of problem?

Improve this question
3

3 Answers 3

Reset to default
9

Breaking stories down can be a real challenge.

One trick is to step away from the original business story and evaluate if it is possible to deliver something smaller but that still produces business value.

Take the story you listed as an example:

"As a user I need to identify our top paying clients so that I can send them a gift"

I would immediately see this as potentially two smaller stories:

"As a marketing manager I want to identify top paying clients so that I can fascilitate future promotions"

and

"As a marketing manager I want to offer promotions to some clients so that they are encouraged to give us more business"

The value from the first stage in the example would be that a list of top paying clients is now available to marketing. But it would only be once the second stage is completed that they would be able to send out gifts to them.

Sometimes it is necessary to introduce an intermediate stage like this to help break a story down. As long as each stage delivers value that is usually OK.

Improve this answer
1
  • 3
    +1 for highlighting the need for intermediate steps, and also for identifying a much more accurate value consumer for the story.
    – Todd A. Jacobs ♦
    Apr 21, 2016 at 20:48
1

When I think about a story, I think of it as a slice of 'what' needs to be done, not bound only to what an end user expects to see (the tip of the iceberg), but bound to the needs of any actor in the system. To that end I've stopped trying to ignore technical stories and am instead trying to embrace them.

If we focus on the what, then we can surface any need as potential independent shipable story. You probably need to partner with your BA to help her expose these needs and craft out the necessary stories.

In this case, the UX developer may have needs, so might an API developer, or an Analytics team member. It's just a case of defining the needs as new stories that can be independently designed and shipped.

As a Reports User I want ... As a UX Developer I want ... As an Analytical Model Developer I want ...

To make it easier for the BA to collaborate with the stakeholders over the backlog - keeping it nicely groomed and prioritized - you can consider using your BA's original story as a kind of top level Feature or Epic.

Improve this answer
4
  • In this case we wouldn't be helping the BA write technical stories, we would be writing the stories for them. There is no intention to train the BA to be more technical. We want the BA to focus on the needs of the business.
    – P.Brian.Mackey
    Apr 21, 2016 at 16:54
  • Just because something is technical it doesn't mean it's a task. If the question is what and not how then it needs a user story. You have to let go of the notion that developers shouldn't be writing stories (or requirements more generally). No one said the BA doesn't focus on the needs of the business FYI.
    – Adrian
    Apr 21, 2016 at 17:01
  • That's an interesting take on the matter. I haven't heard of developers writing stories before. Putting things in the backlog yes; I guess its not too far a leap from that.
    – P.Brian.Mackey
    Apr 21, 2016 at 17:24
  • You should go have a look at the Scrum Guide. While the PO is accountable for stories they need the help of the Development Team to do that well. That'swhy you have up to 10% of your Development Team time for Backlog Refinement.
    – MrHinsh - Martin Hinshelwood
    May 4, 2016 at 5:16
0

You should never bring big stories into the Sprint. There are key mechanisms in Scrum, as described in the Scrum Guide, to facilitate this.

  • Backlog Refinement - Your Product Owner has up to 10% of the Development Teams time to help break the Backlog Items for the next 3 sprints into actionable items.

  • Sprint Planning - Since the Development Team selects what it can do in the Sprint they can refuse to take an item that they don't understand.

    The Product Owner is responsable and accountable for the Product Backlog and everyone's understanding of it.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.