Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Breaking down an epic that includes a lot of tech work - where do you draw the line?

Last post 04:20 am March 5, 2020 by Ian Mitchell
1 reply
02:55 am March 4, 2020

When I started Scrum I was a major proponent of the INVEST principle, especially when it came to Estimable, Small and Testable.  Not that the others weren't important, but I strived in breaking down stories to be as small as possible, and with that they naturally became easy to estimate and easy to test.  When I knew that an epic would require significant technical background work to support the user facing feature, I would generally make that its own story.  I know that violates Independent (which is hard enough to do), and one could argue Valuable as well since it's not directly valuable to end users, but I felt that splitting up the tech background work and user facing work made things more manageable.

An example of this would be retrieving and showing data to the user from an API that doesn't exist yet.  I know based on past stories that creating the API is roughly 3 points using the modified Fibonacci sequence and showing the information on the screen is 2 or 3, depending on how the UI will look.  And there may be other stories depending on business needs, but that gives you an idea.  The API itself meets the E, S and T since QA can test it with Postman, and as I mentioned above it could be argued that is meets V indirectly.

Where do others draw the line between writing a story that only has tech work and a story where the tech work is expected to be included?  Do you wait for Discovery or Estimation where you're told it's too large and needs to be broken up?


04:20 am March 5, 2020

Where do others draw the line between writing a story that only has tech work

Why pretend that's a story at all? It might be a different kind of Product Backlog item.

What matters, in Scrum, is that something of value is delivered every Sprint, even if most of the work has been technically facing. A wise team might implement a small "tracer bullet" user story whiich allows architecture and infrastructure to be validated, for example.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.