Loading ...
Sorry, an error occurred while loading the content.

Re: Neverending Stories

Expand Messages
  • ag12340@rocketmail.com
    Why are you uncomfortable with it? ... They are grouping issues under a story because they need a grouping and the way tool is. Not everything in backlog has
    Message 1 of 17 , Dec 2, 2011
    • 0 Attachment
      Why are you uncomfortable with it?

      >> I presume this is a tracking tool driven "need."
      They are grouping issues under a "story" because they need a grouping and the way tool is. Not everything in backlog has to be a story.

      Are you uncomfortable with the grouping or that tool calls it a story?


      --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
      >
      > We rotate one of our development teams to do support for a period of months. Their work is partly planned, and partly reactive. We have a triage process that looks at incoming issues. We fix critical issues immediately and otherwise create a story for the backlog for the issue. That story will be pointed by the team and prioritized by the customer.
      >
      > Our PO team created a "story" called "Triage." They use it in Mingle to keep track of emerging support tasks. I am uncomfortable with this and I am looking for help making the case that this is not what we really want to be doing. The Triage story ends at the end of the sprint, i.e., the story would be Sprint 109 Triage.
      >
      > I presume this is a tracking tool driven "need."
      >
      > Do you agree with me that this is not best practice and it is a perversion of the notion of a story? How can I persuade the POs to use another approach? Am I missing something?
      >
      > Thanks.
      >
      > Michael
      >
    • Michael Wollin
      I guess I can give that up. It s a zero point story anyway. I just thought it violated the semantics of user story. However, it IS a convenient way to track
      Message 2 of 17 , Dec 2, 2011
      • 0 Attachment
        I guess I can give that up. It's a zero point story anyway. I just thought it violated the semantics of "user story." However, it IS a convenient way to track emergent work, which is a third to half of what this team does. 

        On Dec 2, 2011, at 1:26 PM, ag12340@... wrote:

         

        Why are you uncomfortable with it?

        >> I presume this is a tracking tool driven "need."
        They are grouping issues under a "story" because they need a grouping and the way tool is. Not everything in backlog has to be a story.

        Are you uncomfortable with the grouping or that tool calls it a story?

        --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
        >
        > We rotate one of our development teams to do support for a period of months. Their work is partly planned, and partly reactive. We have a triage process that looks at incoming issues. We fix critical issues immediately and otherwise create a story for the backlog for the issue. That story will be pointed by the team and prioritized by the customer.
        >
        > Our PO team created a "story" called "Triage." They use it in Mingle to keep track of emerging support tasks. I am uncomfortable with this and I am looking for help making the case that this is not what we really want to be doing. The Triage story ends at the end of the sprint, i.e., the story would be Sprint 109 Triage.
        >
        > I presume this is a tracking tool driven "need."
        >
        > Do you agree with me that this is not best practice and it is a perversion of the notion of a story? How can I persuade the POs to use another approach? Am I missing something?
        >
        > Thanks.
        >
        > Michael
        >


      • Michael James
        ... Triage doesn t sound much like a user story to me either, but there s never been a rule in Scrum that all PBIs have to be user stories. Since no one likes
        Message 3 of 17 , Dec 2, 2011
        • 0 Attachment
          On Dec 2, 2011, at 10:31 AM, Michael Wollin wrote:

          > I guess I can give that up. It's a zero point story anyway. I just thought it violated the semantics of "user story." However, it IS a convenient way to track emergent work, which is a third to half of what this team does.

          Triage doesn't sound much like a user story to me either, but there's never been a rule in Scrum that all PBIs have to be user stories.

          Since no one likes fixing operational issues all the time, and interruptions impede your product development, I suppose your longer term goal is to address the quality issues that are probably causing them?

          --mj
        • Michael Wollin
          Rome wasn t built in a day. :) It s progress to have only one of our teams on full time support (they all rotate on and off over time), freeing the other teams
          Message 4 of 17 , Dec 3, 2011
          • 0 Attachment
            Rome wasn't built in a day. :)

            It's progress to have only one of our teams on full time support (they all rotate on and off over time), freeing the other teams for new product development.

            These systems are tricky, a complex Rube Goldberg integration of home grown and external vendor products. Bleeding edge technology, completely integrated global file-based video workflow (satellite, FTP, distributed metadata, editing growing HD video files. etc., and a 30 petabyte digital library). It's another interesting and non-trivial discussion as to how much constitutes overbuilding (vs Lean) belts and braces around these systems. For example, with a video render farm we are using, the servers will choke occasionally on some kinds of video and it's up to us to figure out why, under the pressure sometimes of a breaking news event. I feel sorry for those of you working on yet another ERP or e-commerce web site. :)

            On Dec 2, 2011, at 9:41 PM, Michael James wrote:

            > On Dec 2, 2011, at 10:31 AM, Michael Wollin wrote:
            >
            >> I guess I can give that up. It's a zero point story anyway. I just thought it violated the semantics of "user story." However, it IS a convenient way to track emergent work, which is a third to half of what this team does.
            >
            > Triage doesn't sound much like a user story to me either, but there's never been a rule in Scrum that all PBIs have to be user stories.
            >
            > Since no one likes fixing operational issues all the time, and interruptions impede your product development, I suppose your longer term goal is to address the quality issues that are probably causing them?
            >
            > --mj
            >
            >
            >
            > ------------------------------------
            >
            > To Post a message, send it to: scrumdevelopment@...
            > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
            >
            >
            >
            > /docs.yahoo.com/info/terms/
            >
          • mcleaper
            I never liked having these kinds of activities as stories and it is my belief that they are hold overs from the command and control way of thinking (everything
            Message 5 of 17 , Dec 4, 2011
            • 0 Attachment
              I never liked having these kinds of activities as stories and it is my belief that they are hold overs from the command and control way of thinking (everything the team does must be planned and recorded and it must add up to at least 40 hours per week per person or they will goof off). The PBI was not meant to be used as a time tracker but if the team is comfortable with it and adding that story helps them estimate how many other stories they can handle during the sprint then I would let it be.

              -M

              --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
              >
              > Rome wasn't built in a day. :)
              >
              > It's progress to have only one of our teams on full time support (they all rotate on and off over time), freeing the other teams for new product development.
              >
              > These systems are tricky, a complex Rube Goldberg integration of home grown and external vendor products. Bleeding edge technology, completely integrated global file-based video workflow (satellite, FTP, distributed metadata, editing growing HD video files. etc., and a 30 petabyte digital library). It's another interesting and non-trivial discussion as to how much constitutes overbuilding (vs Lean) belts and braces around these systems. For example, with a video render farm we are using, the servers will choke occasionally on some kinds of video and it's up to us to figure out why, under the pressure sometimes of a breaking news event. I feel sorry for those of you working on yet another ERP or e-commerce web site. :)
              >
              > On Dec 2, 2011, at 9:41 PM, Michael James wrote:
              >
              > > On Dec 2, 2011, at 10:31 AM, Michael Wollin wrote:
              > >
              > >> I guess I can give that up. It's a zero point story anyway. I just thought it violated the semantics of "user story." However, it IS a convenient way to track emergent work, which is a third to half of what this team does.
              > >
              > > Triage doesn't sound much like a user story to me either, but there's never been a rule in Scrum that all PBIs have to be user stories.
              > >
              > > Since no one likes fixing operational issues all the time, and interruptions impede your product development, I suppose your longer term goal is to address the quality issues that are probably causing them?
              > >
              > > --mj
              > >
              > >
              > >
              > > ------------------------------------
              > >
              > > To Post a message, send it to: scrumdevelopment@...
              > > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
              > >
              > >
              > >
              > > /docs.yahoo.com/info/terms/
              > >
              >
            • Dominick Deinde
              Do we generate design documents in scrum and when ?
              Message 6 of 17 , Feb 1, 2012
              • 0 Attachment

                Do we generate design documents in scrum and when ?

                 

              • Chet Hendrickson
                Hello Dominick, Scrum is silent on this point. The development team my use process they like, as long as they meet the agreed upon definition of done.
                Message 7 of 17 , Feb 1, 2012
                • 0 Attachment
                  Re: [scrumdevelopment] Design documents Hello Dominick,

                  Scrum is silent on this point.  The development team my use process they like, as long as they meet the agreed upon definition of done. However, I would suggest you take a quick look a the Agile Manifesto for some additional guidance.

                  chet 



                  Wednesday, February 1, 2012, 11:41:44 AM, you wrote:


                    
                  Do we generate design documents in scrum and when ?
                   




                  -- 
                  Best regards,
                   Chet Hendrickson                          
                  mailto:lists@...
                   Check out our upcoming CSM Plus courses @
                  http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                • Joshua Partogi
                  Yes. Within every Sprint. On Wednesday, February 1, 2012, Dominick Deinde ... -- @jpartogi
                  Message 8 of 17 , Feb 1, 2012
                  • 0 Attachment
                    Yes. Within every Sprint.

                    On Wednesday, February 1, 2012, Dominick Deinde <dominick@...> wrote:
                    >  
                    >
                    > Do we generate design documents in scrum and when ?
                    >
                    >  
                    >
                    >

                    --
                    @jpartogi
                  • George Dinwiddie
                    Dominick, ... Do you need design documents? Who will read them, and when? - George -- ... * George Dinwiddie * http://blog.gdinwiddie.com
                    Message 9 of 17 , Feb 1, 2012
                    • 0 Attachment
                      Dominick,

                      On 2/1/12 11:41 AM, Dominick Deinde wrote:
                      >
                      >
                      > Do we generate design documents in scrum and when ?

                      Do you need design documents? Who will read them, and when?

                      - George

                      --
                      ----------------------------------------------------------------------
                      * George Dinwiddie * http://blog.gdinwiddie.com
                      Software Development http://www.idiacomputing.com
                      Consultant and Coach http://www.agilemaryland.org
                      ----------------------------------------------------------------------
                    • Dominick Deinde
                      We have design documents as deliverables for the software development process now. My client will like to keep them as part of scrum when we convert. According
                      Message 10 of 17 , Feb 1, 2012
                      • 0 Attachment
                        We have design documents as deliverables for the software development
                        process now. My client will like to keep them as part of scrum when we
                        convert. According to some of my research, we can do high level design such
                        as architecture at sprint 0. Then spend 4 hrs discussion during each sprint
                        for detailed design. What do you think ?

                        -----Original Message-----
                        From: scrumdevelopment@yahoogroups.com
                        [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
                        Sent: Wednesday, February 01, 2012 6:11 PM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] Design documents

                        Dominick,

                        On 2/1/12 11:41 AM, Dominick Deinde wrote:
                        >
                        >
                        > Do we generate design documents in scrum and when ?

                        Do you need design documents? Who will read them, and when?

                        - George

                        --
                        ----------------------------------------------------------------------
                        * George Dinwiddie * http://blog.gdinwiddie.com
                        Software Development http://www.idiacomputing.com
                        Consultant and Coach http://www.agilemaryland.org
                        ----------------------------------------------------------------------



                        ------------------------------------

                        To Post a message, send it to: scrumdevelopment@...
                        To Unsubscribe, send a blank message to:
                        scrumdevelopment-unsubscribe@...! Groups Links
                      • Gary Brown
                        Hello, Dominick! ... Here is what I do. If a project is guess-timated to take three months, I take about a week to establish team working agreements (you can
                        Message 11 of 17 , Feb 1, 2012
                        • 0 Attachment
                          Hello, Dominick!

                          Quoting Dominick Deinde <dominick@...>:

                          > We have design documents as deliverables for the software development
                          > process now. My client will like to keep them as part of scrum when we
                          > convert. According to some of my research, we can do high level design such
                          > as architecture at sprint 0. Then spend 4 hrs discussion during each sprint
                          > for detailed design. What do you think ?

                          Here is what I do. If a project is guess-timated to take three
                          months, I take about a week to establish team working agreements (you
                          can omit or reduce this for mature Agile teams), about a week to
                          understand the requirements and learn about things we don't know, and
                          about a week to establish the high level system design. I call that
                          HLD the essential abstraction. What I mean by that is here are the
                          set of components we need, and here are the things they need to do.
                          Don't get stuck on tools or techniques, just focus on WHAT needs to be
                          done. Draw the picture, call it done.

                          Build the system story by story, doing the simplest thing that could
                          possibly work. That means, building exactly what is needed for now,
                          contains no duplication, passes all of the tests, and clearly reveals
                          its intent. Nothing more, nothing less.

                          As you pick up each new story, ask what do we need to do to make this
                          fit easily into the design. Refactor first, then add the new design
                          element. Do this every time, and you can hold entropy at arms length
                          indefinitely.

                          GB.



                          ----------------------------------------------------------------
                          This message was sent using IMP, the Internet Messaging Program.
                        • JackM
                          Yes most definitely if you need it. If you don t then don t do it. Always think about who is consuming this document. Will you be able to keep it up-to-date.
                          Message 12 of 17 , Feb 1, 2012
                          • 0 Attachment
                            Yes most definitely if you need it. If you don't then don't do it.

                            Always think about who is consuming this document. Will you be able to keep it up-to-date. Most documents are out of date from the moment the pen goes down. But there are many cases where documents are needed and those should be delivered just like other aspects of software development is delivered. Create a task for it, make it part of the acceptance test criteria for the story etc.

                            Hope this helps
                            Jack
                            www.agilebuddy.com

                            --- In scrumdevelopment@yahoogroups.com, "Dominick Deinde" <dominick@...> wrote:
                            >
                            > Do we generate design documents in scrum and when ?
                            >
                          • Kurt Häusler
                            I am a fan of generating requirements documentation in the form of executable acceptance tests, specifications in the form of unit tests, and a detailed design
                            Message 13 of 17 , Feb 1, 2012
                            • 0 Attachment
                              I am a fan of generating requirements documentation in the form of executable acceptance tests, specifications in the form of unit tests, and a detailed design of the software in the form of compilable or runnable source code.


                              On Feb 1, 2012, at 5:41 PM, Dominick Deinde wrote:

                              >
                              > Do we generate design documents in scrum and when ?
                            • George Dinwiddie
                              Dominick, ... Consider the documents the same as you do code, then. I wouldn t spend too much effort on them along the way, as the design of the code is likely
                              Message 14 of 17 , Feb 1, 2012
                              • 0 Attachment
                                Dominick,

                                On 2/1/12 8:29 PM, Dominick Deinde wrote:
                                > We have design documents as deliverables for the software development
                                > process now. My client will like to keep them as part of scrum when we
                                > convert. According to some of my research, we can do high level design such
                                > as architecture at sprint 0. Then spend 4 hrs discussion during each sprint
                                > for detailed design. What do you think ?

                                Consider the documents the same as you do code, then. I wouldn't spend
                                too much effort on them along the way, as the design of the code is
                                likely to change if you're doing increment design. But keep enough
                                information that you feel confident you can write the necessary
                                documents at the end, of the "as built" system.

                                - George

                                --
                                ----------------------------------------------------------------------
                                * George Dinwiddie * http://blog.gdinwiddie.com
                                Software Development http://www.idiacomputing.com
                                Consultant and Coach http://www.agilemaryland.org
                                ----------------------------------------------------------------------
                              • ashish_wrt
                                I tried Scrum both ways with and without design upfront and now I do Scrum only with design upfront (usually light) and a design review before coding starts
                                Message 15 of 17 , Feb 2, 2012
                                • 0 Attachment
                                  I tried Scrum both ways with and without design upfront and now I do Scrum only with design upfront (usually light) and a design review before coding starts for anything not very simple. Sometimes I go for comprehensive and detailed design.

                                  In most cases design document is only a wiki page with two diagrams or something the developer explains on board on how they plan to do it and we take a pic and put it on our wiki with additional notes by the developer.

                                  It is part of the sprint and usually before the developer starts coding.

                                  During coding developer is free to deviate from his original design and regroup with team to discuss and communicate his changes.

                                  Value is in thinking through and getting input.

                                  Ashish
                                  http://www.agilewrap.com


                                  --- In scrumdevelopment@yahoogroups.com, "Dominick Deinde" <dominick@...> wrote:
                                  >
                                  > Do we generate design documents in scrum and when ?
                                  >
                                Your message has been successfully submitted and would be delivered to recipients shortly.