Skip to main content

Technical stories

Last post 08:58 am February 5, 2019 by Robert Shandley
5 replies
03:36 pm February 4, 2019

We always think in backlog with user stories. 

But What happen when the issue is from other system and not from a user?

For exemplo: I have one "enabled squad"  that develop technical components for many areas in my company.

Is everything OK if my storie use just a description and not a convencional structure,?

What do you think about?

Convercional structure means:

As an user

I would like to

...

In order to:

...


04:21 pm February 4, 2019

Everything would be OK.  Scrum does not prescribe how to describe a Product Backlog item.  The User Story ubiquitous structure you describe is a complimentary practice, but by no means required.

So describe it however your Development Team will understand it. And always remember that the conversation is even more important.


07:19 pm February 4, 2019

@Chris is completely correct.  As long as you communicating the needed information in a form that everyone understands and there is some way to know if the problem has been successfully addressed, anything is OK. 

If your development wants to have a "story" format, there are numerous ones that can be used.  I have had some success with these two.

  • In order to <deliver some benefit> <these people> will need <this function>.
  • In order to <deliver some benefit> <this system> must <deliver this function>.

08:26 pm February 4, 2019

For exemplo: I have one "enabled squad"  that develop technical components for many areas in my company.

Is everything OK if my storie use just a description and not a convencional structure,?

A Product Backlog item ought to have a description, a value, an order, and an estimate. How would you describe the value being provided by these "technical" items, so that valuable feature-complete increments can be planned and delivered?


05:18 am February 5, 2019

You can create these technical stories as enablers stories.

Multiple user stories can be dependent on this story.


08:58 am February 5, 2019
  • In order to <deliver some benefit> <this system> must <deliver this function>.

@Daniel: I like that one. Thanks. 


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.