User Stories for Production or General Support

First: There are no "resources". You might have co-workers, colleagues or employees. "Resources" are dump material, and people most certainly are not.

Scrum is meant to work in "complex" environments. Production is usually "simple" while support often is "complicated". So maybe you chose the wrong tool for your situation.

In regards to your problem: I would divide them in two. First: How to make sure to bill your customer right. Well, in that case you might want to have your PO reserve some time and bill it. Spare your team that pain.
Second: How to organize work in your team. How about stating your issue to the team and having them solve it? Maybe they come up with something like reducing the velocity or the capacity during Sprint Planning and then write meaningful tasks (or even stories) when actual work starts dripping in; maybe they will find a completely different approach.

By the way: All work somehow comes from the Product Owner. It is only done if she sees value in it. If she does see value in it, she will be able to state it in a user story. If not, she should try to get rid of it.

Hi Briana,

Besides what Dominik has mentioned, don't try so hard to make everything into User stories. User stories was meant to help development team and business people to communicate on requirements. If you spend a lot of time trying to make everything into user stories, you might as well use something else that gets you up to speed. From my personal experience, most production issues doesn't have to be written in user stories either because it is very small or not related with user interface (backend related).

HTH

Thanks for the feedback!

I don't disagree that the wrong tool was chosen. Unfortunately, that decision is beyond my control. And the product owner insists on using User Stories to capture ALL work, rather than reducing velocity or capacity during sprint planning.

Is there still a way to make sense of this and do it well (if not exactly right)?

> Is there still a way to make sense of this and do it well (if not exactly right)?

What you can do is to vary the quality of service being provided according to the user story. This isn't Scrum, but a hybrid called Scrumban. Many Scrumban teams will have a fast-track lane specifically for support work. Then, if a Sprint Goal is compromised because of unplanned tasks being fast-tracked, the reasons will be captured in the stories themselves. Perhaps this is what your Product Owner is actually wanting?

Whatever you do, avoid reserving any *particular* person for handling requirements, regardless of whether they are planned or not. The team should self-organise around who should handle the work. So if a support requirement is fast tracked, the team should swarm over it. Once a response is determined, those who do not need to be involved will return to their original stories.

A very strong +++++1 to what Dominik and Joshua said.

It sounds like you have multiple misunderstandings going on. A user story is not a sentence. I co-authored the Agile Atlas article on User Stories, and while a sentence might convey the "title" (aka card) of a user story -- a User Story is not a sentence. If you want to see what a User Story is, check out this article:
http://agileatlas.org/gasps/article/user-stories
and this one
http://www.scrumcrazy.com/A+User+Story+Checklist

> product owner insists on using User Stories to capture ALL work, rather than reducing velocity
Based on what you've said, your PO does not understand Scrum or User Stories. You might want to see about getting some scrum coaching for him/her.

Regardless of Scrum or the terminology, I certainly hope that your PO understands that when he/she brings work in mid-sprint, that the Dev Team has the right to drop some other work that is currently in the sprint. If the PO doesn't understand that, it could bring great harm and risk to your company over the long haul. Trying to fit 10 pounds into a five pound bag leads to Enron type situations, where it becomes too late and your company has jumped off a cliff without a parachute.

> product owner insists on using User Stories to capture ALL work, rather than reducing velocity

One more comment about the above. The PO has no role in deciding how Scrum is implemented. The Scrum Master manages the Scrum implementation. It sounds like your PO is command and controlling the team, so you as the Scrum Master may want to see how you can remove this impediment.

Is there still a way to make sense of this and do it well (if not exactly right)?

Hi Briana,

Can you ask the PO first why he insists on capturing every work into user stories?

If the PO can explain his reasons, you can ask him to teach you how to make a good user stories for the work your team is handling.

If it turns out that he is just following the trend without knowing why he wants to use User stories, you can negotiate with him and persuade him to use more effective tool to capture the work.

;-)

>> If it turns out that he is just following the trend without knowing why he wants to use User stories, you can negotiate with him and persuade him to use more effective tool to capture the work.

I'm worried this may be the case, but being fairly new to it myself I'm still trying to learn. Thank you all for your input! This is very insightful and will definitely help! :)

Won't such user stories be more time consuming?

_________
http://www.agiledistributed.com/