11

Are technical user stories allowed in Scrum? If so, what is the standard template for writing technical user stories in Scrum? Is it the same As a <user> I want to do <task> so that I can <goal> ??

I have read in some blogs that as-a-developer-is-not-a-user-story, but I have also read that Scrum does not mandate these. There are few blogs where they have shared user stories with system as user, its like as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. So which one is the standard?

For instance, there are user stories like:

As a reviewer I want to upload photos of any hotel/food so that other users can see and like them

As a user I want to add photo comments so that I can explain my view better

Now for both these user stories, there is a big technical item - Saving and retrieving the image

So can I add a technical story titled "Image storing and retrieving mechanism", with the following description?

As a developer I want to develop a mechanism to store and retrieve images so that users can add/view images wherever required

  • 6
    "Image storing and retrieving mechanism" shouldn't be a technical story but a developer task attached to your first user story. – guillaume31 Aug 6 '15 at 12:47
13

Technical stories are allowed, but I would advise you to try to avoid them as much as you can.

For example, your story for saving and retrieving images can easily be written as two regular user-stories

  1. As a reviewer, I want my uploaded photos to be stored persistently, so that other users can view them at any time.
    (Note that this assumes that in your original upload story, the image will not be persistently stored after the upload. Although this might look strange, it is a valid way of splitting up stories to make them manageable.)
  2. As a user, I want to view uploaded images at a moment that is convenient for me.
    (This implies that stored images can be retrieved later.)

Technical stories should be reserved for work that is important for the organization, but not directly visible as a feature/functionality to the users. For example, adding load balancing to handle larger number or requests.

  • 3
    Even something like load balancing is just a result of a user wanting the system to perform better, so this isn't any different than any other implementation. They want to save data, but couldn't care less about a database. – JeffO Aug 7 '15 at 0:32
  • @JeffO is exactly right. Even those stories should be phrased in the context of the value to the user so that they are prioritized and assessed accordingly. Without doing so you could easily lose sight of the fact that you don't yet have enough load to warrant load-balancing, so the story can be put off for a few months until the sales team works a little harder ;) Mike Cohn talks about this in the book Suceeding with Agile. – pbarranis Dec 10 '15 at 15:19
  • Would there be such a case where user story doesn't apply? For example, what are the example of user stories that we will see, if you are told to build a Artificial Intelligent:alphaGO, and the ultimate goal is to beat human in GO? Who would be the user that I can interview to define expectations/acceptance criterias ? – Roy Lee Mar 17 '16 at 7:11
11

The question, given your particular example, would be why does a developer want to develop a mechanism to store and retrieve images so that users can add/view images wherever required, unless a user wants to add or view images?

That is, while your question is a good one, the example isn't. This is a user feature and should have a user story. And if the user doesn't really need that functionality then the developer shouldn't want to do it.

A technical story is more "As a developer, I want to reduce duplication in the data-archiving modules, so that I don't have to make every change in 6 places."

The question of whether these should be included in the sprint is a difficult one, and it depends somewhat who you consider to be your customer. Is it the end user, or the business who employs you, or the business who employs the business who employs you?

A lot of industry opinion-guiding is done by people who work for consultancy companies. From that perspective, I can see the argument that developer stories are bad. They should just be a part of what you do, day-to-day, invisible to the company that's paying for it. Those companies instinctively know that running up the bills too high ensures that your work dries up, so every developer works on a principle of doing only technical development that improves your development time, or improves your ability to release bug-free software.

My experience is more with working on in-house teams, providing software directly to the company who pays my wages. In many of those companies, there is a trust barrier between the business and the technical wing of the business. In all of them, there is a different mentality, where decreasing costs are every bit as increasing income.

In those environments, it can be good to define significant developer stories. It increases visibility, engendering trust, and encourages developers and management alike to think about the value of such tasks to the business and prioritise accordingly.

Ultimately, I suggest you try it. And, if it doesn't offer value, stop doing it.

But my instinct says that if you were considering the value of this development to the business, you wouldn't even have tried to make it a developer story. It's either good for the end user or it isn't. If it isn't then there's no value to the business.

  • 1
    Would there be such a case where user story doesn't apply? For example, if you are told to build a Artificial Intelligent:alphaGO, and the ultimate goal is to beat human in GO? How should I create the user stories, who would the actors of the stories, and who (would it be product owner? or consumer?) should I interview to define expectations/acceptance criterias? – Roy Lee Mar 17 '16 at 7:16
2

This is a good question. I don't have an official answer but where I work we add technical user stories and call them technical debt. If they weren't permitted, I would find some other way to get them added for the mere purpose of having my work recorded and communicated to the business. Likewise, having this documentation reminds us of what is needed for future projects.

As an example, the disconnect in a new application, if we're not allowed to add technical stories, is that I'll be humming along for a week after the start of a sprint creating database models and waiting for my data modeler to approve them, iterate w/ the modeler and when done send the scripts to the dba and wait for them to create the db objects. In the meantime, I'll create a new code project, some base ORM functionality, and my source control layout and when all is said and done I'll have time to create one blank landing page and deploy.

Day by day while this is going on, if I don't record the info, the business is clambering that our team is not working on the project when in fact we are. Having these items in the stories means that we can check off our work, have documented work, and communicate to the business that we're making progress.

If there's a better best practice to do this I'm all ears.

  • Although an issue in many organizations, the 100% utilization fallacy is a common dysfunction. ASIDE: Technical debt is a known concern involving needed work that is deliberately delayed. – Alan Larimer Mar 22 '18 at 16:26
2

My personal feeling is that teams should not be too hung up on what scrum allows and be more worried about what works for the team. Part of the reason that scrum has gotten a bit of a bad reputation is that practitioners can become process focused which is antithetical to the ideas behind agile project management.

I'll get off of my soapbox now but if you question whether the below is really 'scrum', please (re)read the above.

It's important to separate the 'features' that the user stories define and the 'deliverables' that the technical team needs to deliver in order to support those features. In this case need to save and retrieve pictures is a technical deliverable that you (as the technical team) need to implement. Pretty much every story will need some technical deliverables.

The reason that this is important is that a technical deliverable (by itself) is not something that produces value from a user perspective. If you start tracking technical deliverables as user stories, you can easily fall into the trap of treating technical output as producing business value. Muddying the waters in this way will confuse work that supports business objectives (i.e. things that cost money) with actual business objectives (i.e. things that make money.)

  • Crap, I didn't notice this was an old question... – JimmyJames Feb 23 '18 at 16:01
  • Nah, it's a good answer. Kudos! – Hannele Feb 23 '18 at 17:10
  • teams should not be too hung up on what scrum allows is problematic. It is a key reason that the Scrum framework continues to be misunderstood. Cargo cults that aren't even correct in practice are perpetuated through ongoing ignorance. – Alan Larimer Mar 21 '18 at 15:44
  • @AlanLarimer There is more to agile than scrum. The point of agile is to build processes that work for teams. I would agree that calling something scrum when it's not is problematic but I reject the notion that scrum is the pinnacle of project management processes. – JimmyJames Mar 21 '18 at 16:12
  • Agreed that the agile philosophy promotes adaptive approaches to product (over project, as Scrum is focused) development and that there is no silver bullet. Nobody claiming a pinnacle status in this Q&A. When teams/orgs/groups choose the Scrum framework and have questions regarding its use, then highlighting that it is a framework that supports (as it was a foundation of) the agile philosophy through not prescribing many specifics is key. Realizing value in such flexibility, and others, is important to avoiding cargo cults and identifying the difference between framework and process issues. – Alan Larimer Mar 21 '18 at 16:39
1

All of the above answers fail to reference the authoritative source document for the Scrum framework: The Scrum Guide.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

The focus should be on producing value. Sometimes that value comes from technical work, such as upgrading infrastructure. Don't exclude those items!

The term user story never appears in The Scrum Guide because

it is a framework within which you can employ various processes and techniques.

Using a user story is just one possible technique for recording the PBIs. Although it is common to see the "As a, I want, So that" format, it can be counter to its original intent. This troublesome format was also addressed at Agile 2017.

Understanding and utilizing vertical slicing will be helpful for reducing the size of the Product Backlog items (PBIs). Consider slicing that single save and Retrieve item into save and retrieve items.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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