Forums

By posting to our forums you are agreeing to the Forum terms of use.
User Stories for Production or General Support
Last Post 07 Jun 2013 07:55 AM by alicemenezes. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Briana
New Member
New Member
Posts:4
Briana

--
29 May 2013 09:35 AM
    Hello!

    I'm a new ScrumMaster for a team whose focus is on integration with external systems and support to our primary software suite. Our client encourages us to capture all work in User Stories, but we are struggling with how to craft meaningful user stories to represent work that does not result in the delivery of system functionality or artifacts.

    An example of something we struggle with is how to capture "buckets" of time for a given resource to support an environment or external application. I may be asked to reserve 15% of a particular resource's time for support, but I also need to capture this in a User Story that provides enough detail to be meaningful to the Product Owner.

    Does anyone have any advice or examples of how to create a meaningful user story for this purpose?

    Thanks!
    Dominik Maximini
    New Member
    New Member
    Posts:64
    Dominik Maximini

    --
    30 May 2013 11:59 AM
    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.
    Joshua Partogi
    New Member
    New Member
    Posts:98
    Joshua Partogi

    --
    30 May 2013 12:51 PM
    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
    Briana
    New Member
    New Member
    Posts:4
    Briana

    --
    31 May 2013 10:28 AM
    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)?
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:569
    Ian Mitchell

    --
    31 May 2013 11:03 AM
    > 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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    31 May 2013 12:25 PM
    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...er-stories
    and this one
    http://www.scrumcrazy.com/A+User+St...+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.



    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    31 May 2013 12:27 PM
    > 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.
    Joshua Partogi
    New Member
    New Member
    Posts:98
    Joshua Partogi

    --
    02 Jun 2013 04:11 AM
    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?
    Joshua Partogi
    New Member
    New Member
    Posts:98
    Joshua Partogi

    --
    02 Jun 2013 04:15 AM
    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.

    ;-)
    Briana
    New Member
    New Member
    Posts:4
    Briana

    --
    03 Jun 2013 08:58 AM
    >> 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! :)
    alicemenezes
    New Member
    New Member
    Posts:39
    alicemenezes

    --
    07 Jun 2013 07:55 AM
    Won't such user stories be more time consuming?

    _________
    http://www.agiledistributed.com/
    You are not authorized to post a reply.


    Feedback