AnsweredAssumed Answered

How to break down large user stories

Question asked by clayton.lemons on Feb 1, 2018
Latest reply on Feb 5, 2018 by William Kammersell

This is more of a general question about agile best practices, so feel free to redirect me if there is a better space to bring it up.

 

My problem is that I'm having trouble breaking down a user story into smaller user stories, without getting into the jungle of technical details.

 

To give some background, I'm providing hardware support for a new device in my driver API. The API is generally the same across all supported devices, so I already know what my high level user stories need to be. The problematic user story that I'm having trouble breaking down is, "As a calibration API user, I want to self calibrate the device." (I decided not to define this user story as an epic because there is a lot more functionality related to calibration.)

 

From the user's perspective, self calibration is simple: call the API function that performs self calibration! There are no options or parameters; the function does exactly what it says it will do. However, implementing self calibration is actually quite involved from a software perspective. It requires implementing a complex procedure with lots of math, which historically has taken several months of research and back-and-forth with analog and digital engineers in order to define the procedure. It terms of work breakdown, I'd like to capture this work somehow.

 

My first thought for capturing the work was to bucket all the tasks under the high level user story, but that seems like the wrong direction, especially since I already know the user story isn't going to fit within a single sprint, probably not even two! My second thought was to break down the user story even further, but I'm concerned about revealing too much technical detail in the child user stories that the user wouldn't (and shouldn't) know about. For example, I could write this child user story, "As a calibration API user, I want to self calibrate the device so the magic constants are accurate". This user story is big enough to count as a child user story, yet small enough to fit within a sprint. However, end users should know absolutely nothing about the *magic* constants!

 

So, my real question is this: is my concern about revealing too much technical detail irrational? Am I thinking about user stories all wrong?

 

Any feedback is appreciated!

Outcomes