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

RE: [scrumdevelopment] Is it possible as a scrumteam to plan in our own stories in the sprint?

Expand Messages
  • Roy Morien
    I am sure that it is possible, but is it useful? It is a little bit odd that there is a backlog bigger than what can be planned for the next few sprints. There
    Message 1 of 11 , Apr 1, 2009
    • 0 Attachment
      I am sure that it is possible, but is it useful? It is a little bit odd that there is a backlog bigger than what can be planned for the next few sprints. There seems tobe something a little useless about that.
       
      Presuming that the PO is the one you need to keep happy, why are you trying to buck the system by introducing your own stories? And what exactly is a QC-improvement story? I would think that if you want to improve QC then that will be kinda built-in to your on-going efforts without a User Story. Perhaps introducing new QC/Qa procedures might slowyou down a bit to start, though. But you don't really use User Stories do bookmark development procedure activities.
       
      Regards,
      Roy Morien
       

      To: scrumdevelopment@yahoogroups.com
      From: paul.mestrum@...
      Date: Wed, 1 Apr 2009 07:44:17 +0000
      Subject: [scrumdevelopment] Is it possible as a scrumteam to plan in our own stories in the sprint?

      I'm the scrummaster of a software engineering team that creates, updates and maintains production software used to generate data-products. We want to work on a better nightly build environment with a lot more QC on the data-products, but the backlog that is maintained by our product owner is bigger than what can be planned in during the next sprints. That's why that our QC-improvement stories are postponed without a real guarantee when we will be able to work on. As a team, we are convinced that the added value after 2 or 3 sprints will be that big that our velocity will increase significantly. Is it possible, as a scrumteam, to plan in our own stories, even if the product owner disagrees?




      Click Here View photos of singles in your area
    • Ron Jeffries
      Hello, Paul. On Wednesday, April 1, 2009, at 3:44:17 AM, you ... Possible, certainly. Consequences don t seem good. Can you improve the build incrementally,
      Message 2 of 11 , Apr 1, 2009
      • 0 Attachment
        Hello, Paul. On Wednesday, April 1, 2009, at 3:44:17 AM, you
        wrote:

        > Is it possible, as a scrumteam, to plan in our own stories, even
        > if the product owner disagrees?

        Possible, certainly. Consequences don't seem good.

        Can you improve the build incrementally, as part of each story?

        > but the backlog that is maintained by our product owner is bigger
        > than what can be planned in during the next sprints.

        It's supposed to be. It is the sole job of the PO to choose stories
        to get the best product done by the date, at the speed the
        developers can accomplish.

        It is worth noting that higher speed would get more stories done.
        Can you honestly offer higher speed for some investment? How much?

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        Attend our CSM Plus Course!
        http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
        New and stirring things are belittled because if they are not belittled,
        the humiliating question arises, "Why then are you not taking part in
        them?" -- H. G. Wells
      • shankar moorthy
        Hi Paul The objective of the team would be to satisfy the PO(Hope he is funding the job).If you think the team will have a lot more time in the sprint,you can
        Message 3 of 11 , Apr 1, 2009
        • 0 Attachment
          Hi Paul

          The objective of the team would be to satisfy the PO(Hope he is funding the job).If you think the team will have a lot more time in the sprint,you can improve processes.However,I doubt if you would need user stories to support the action.

          Rgds 
          Shankar Kris
          1 847 363 1675



          From: Paul Mestrum <paul.mestrum@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Wednesday, April 1, 2009 2:44:17 AM
          Subject: [scrumdevelopment] Is it possible as a scrumteam to plan in our own stories in the sprint?

          I'm the scrummaster of a software engineering team that creates, updates and maintains production software used to generate data-products. We want to work on a better nightly build environment with a lot more QC on the data-products, but the backlog that is maintained by our product owner is bigger than what can be planned in during the next sprints. That's why that our QC-improvement stories are postponed without a real guarantee when we will be able to work on. As a team, we are convinced that the added value after 2 or 3 sprints will be that big that our velocity will increase significantly. Is it possible, as a scrumteam, to plan in our own stories, even if the product owner disagrees?


        • William Berger
          Reading this post gives the distinct impression that you perceive there are rules to how Scrum works. My understanding is that there are guidelines and
          Message 4 of 11 , Apr 1, 2009
          • 0 Attachment
            Reading this post gives the distinct impression that you perceive there are rules to how Scrum works. My understanding is that there are guidelines and principles, not hard-n-fast rules. I believe Scrum is not intended to be a playbook with rules to run a scrum by, but rather a set of guidelines to be considered as the scrum team figures out how to most effectively build the software functionality the PO deems most desirable (and 'pays' for) for any given sprint.

            So, I'd first recommend that:

            > "Is it possible, as a scrumteam, to plan in our own stories,
            > even if the product owner disagrees?"

            is a moot point for this forum. The implicit answer is "Of course it's possible" from a Scrum philosophy perspective.

            But I suspect that's not the intent of the question. You cannot get "advice" from this group that will enable you to bypass your own internal politics. It seems to me you're looking for permission to do something your team deems appropriate for more effective software creation but haven't gotten the 'go-ahead' to do it for whatever reason (including not having asked yet).

            If your workday is governed solely by what backlog items exist in your sprint backlog, then this is really a question for your PO. Bottom line, you need to convince the PO that taking the time (possibly incrementally over a few sprints) to make adjustments to your team's development process can have positive benefits for the PO's investment to "allow" it to happen.

            Of course, there is the philosophy of self-organization in Scrum. If your organization supports self-organization deeply enough, I would suggest you need not get permission - that the team decides what workday efforts are appropriate to complete a sprint once the sprint backlog has been decided. So, you could simply have the team agree to fewer backlog items and roll the process improvement into the development process (again, possibly incrementally) until complete. Your team velocity may take a hit, but then again, so does the speed of a sailboat as you adjust your sails to take better advantage of atmospheric conditions.

            Bill Berger
          • Nicolas Mohamed
            I don t know if it s ok or not, but it happens and that s the main point We (as a team) defined for this current sprint a task called rename objects in the
            Message 5 of 11 , Apr 1, 2009
            • 0 Attachment
              I don't know if it's ok or not, but it happens and that's the main point

              We (as a team) defined for this current sprint a task called "rename objects in the entity framework model". We did this because we have an architecture team which approves (or not) our code.

              If the code is not approved, it won't go to prod => PO will never see all the business value

              ¿Should we eliminate this task? ¿Should we do it silently consuming hours from other tasks? The PO does not even know it exists and we cannot show it in a demo because is not something visible.


              Nicolas

              ----------------------------------------------------
              www.unavisiondistinta.blogspot.com



              On Wed, Apr 1, 2009 at 2:36 PM, William Berger <Bill.Berger@...> wrote:

              Reading this post gives the distinct impression that you perceive there are rules to how Scrum works. My understanding is that there are guidelines and principles, not hard-n-fast rules. I believe Scrum is not intended to be a playbook with rules to run a scrum by, but rather a set of guidelines to be considered as the scrum team figures out how to most effectively build the software functionality the PO deems most desirable (and 'pays' for) for any given sprint.

              So, I'd first recommend that:

              > "Is it possible, as a scrumteam, to plan in our own stories,
              > even if the product owner disagrees?"

              is a moot point for this forum. The implicit answer is "Of course it's possible" from a Scrum philosophy perspective.

              But I suspect that's not the intent of the question. You cannot get "advice" from this group that will enable you to bypass your own internal politics. It seems to me you're looking for permission to do something your team deems appropriate for more effective software creation but haven't gotten the 'go-ahead' to do it for whatever reason (including not having asked yet).

              If your workday is governed solely by what backlog items exist in your sprint backlog, then this is really a question for your PO. Bottom line, you need to convince the PO that taking the time (possibly incrementally over a few sprints) to make adjustments to your team's development process can have positive benefits for the PO's investment to "allow" it to happen.

              Of course, there is the philosophy of self-organization in Scrum. If your organization supports self-organization deeply enough, I would suggest you need not get permission - that the team decides what workday efforts are appropriate to complete a sprint once the sprint backlog has been decided. So, you could simply have the team agree to fewer backlog items and roll the process improvement into the development process (again, possibly incrementally) until complete. Your team velocity may take a hit, but then again, so does the speed of a sailboat as you adjust your sails to take better advantage of atmospheric conditions.

              Bill Berger


            • Pablo Emanuel
              Nicolas, Is the PO supposed to see tasks (HOW)? Isn t (s)he only interested in stories (WHAT) and estimates/commitments (HOW MUCH/WHEN)? Regards, Pablo Emanuel
              Message 6 of 11 , Apr 1, 2009
              • 0 Attachment
                Nicolas,
                 
                Is the PO supposed to see tasks (HOW)? Isn't (s)he only interested in stories (WHAT) and estimates/commitments (HOW MUCH/WHEN)?
                 
                Regards,
                Pablo Emanuel

                2009/4/1 Nicolas Mohamed <nicolasmohamed@...>

                I don't know if it's ok or not, but it happens and that's the main point

                We (as a team) defined for this current sprint a task called "rename objects in the entity framework model". We did this because we have an architecture team which approves (or not) our code.

                If the code is not approved, it won't go to prod => PO will never see all the business value

                ¿Should we eliminate this task? ¿Should we do it silently consuming hours from other tasks? The PO does not even know it exists and we cannot show it in a demo because is not something visible.


                Nicolas

                ----------------------------------------------------
                www.unavisiondistinta.blogspot.com





                On Wed, Apr 1, 2009 at 2:36 PM, William Berger <Bill.Berger@...> wrote:

                Reading this post gives the distinct impression that you perceive there are rules to how Scrum works. My understanding is that there are guidelines and principles, not hard-n-fast rules. I believe Scrum is not intended to be a playbook with rules to run a scrum by, but rather a set of guidelines to be considered as the scrum team figures out how to most effectively build the software functionality the PO deems most desirable (and 'pays' for) for any given sprint.

                So, I'd first recommend that:

                > "Is it possible, as a scrumteam, to plan in our own stories,
                > even if the product owner disagrees?"

                is a moot point for this forum. The implicit answer is "Of course it's possible" from a Scrum philosophy perspective.

                But I suspect that's not the intent of the question. You cannot get "advice" from this group that will enable you to bypass your own internal politics. It seems to me you're looking for permission to do something your team deems appropriate for more effective software creation but haven't gotten the 'go-ahead' to do it for whatever reason (including not having asked yet).

                If your workday is governed solely by what backlog items exist in your sprint backlog, then this is really a question for your PO. Bottom line, you need to convince the PO that taking the time (possibly incrementally over a few sprints) to make adjustments to your team's development process can have positive benefits for the PO's investment to "allow" it to happen.

                Of course, there is the philosophy of self-organization in Scrum. If your organization supports self-organization deeply enough, I would suggest you need not get permission - that the team decides what workday efforts are appropriate to complete a sprint once the sprint backlog has been decided. So, you could simply have the team agree to fewer backlog items and roll the process improvement into the development process (again, possibly incrementally) until complete. Your team velocity may take a hit, but then again, so does the speed of a sailboat as you adjust your sails to take better advantage of atmospheric conditions.

                Bill Berger



              • davenicolette
                Hi Nicolas, Do you think renaming objects in a model would take a significant amount of time? It doesn t *sound* like a big deal, on the surface. If not, then
                Message 7 of 11 , Apr 1, 2009
                • 0 Attachment
                  Hi Nicolas,

                  Do you think renaming objects in a model would take a significant amount of time? It doesn't *sound* like a big deal, on the surface. If not, then just do it as you work through other items.

                  Did the team know of the naming conventions required to go to prod? If so, then why didn't they follow the required conventions the first time?

                  If the team didn't have that information, then why not? Could be a communication breakdown in the organization, or a lack of collaboration with the architecture team at the start of the project. These are not the PO's problem. Non-functional requirements and organizational standards are the technical team's responsibility.

                  You may not be able to demo this directly, but you can certainly explain the situation to the PO. I'll bet he isn't stupid.

                  Cheers,
                  Dave

                  --- In scrumdevelopment@yahoogroups.com, Nicolas Mohamed <nicolasmohamed@...> wrote:
                  >
                  > I don't know if it's ok or not, but it happens and that's the main point
                  >
                  > We (as a team) defined for this current sprint a task called "rename objects
                  > in the entity framework model". We did this because we have an architecture
                  > team which approves (or not) our code.
                  >
                  > If the code is not approved, it won't go to prod => PO will never see all
                  > the business value
                  >
                  > ¿Should we eliminate this task? ¿Should we do it silently consuming hours
                  > from other tasks? The PO does not even know it exists and we cannot show it
                  > in a demo because is not something visible.
                  >
                  >
                  > Nicolas
                  >
                  > ----------------------------------------------------
                  > www.unavisiondistinta.blogspot.com
                  >
                  >
                  >
                  > On Wed, Apr 1, 2009 at 2:36 PM, William Berger <Bill.Berger@...>wrote:
                  >
                  > > Reading this post gives the distinct impression that you perceive there
                  > > are rules to how Scrum works. My understanding is that there are guidelines
                  > > and principles, not hard-n-fast rules. I believe Scrum is not intended to be
                  > > a playbook with rules to run a scrum by, but rather a set of guidelines to
                  > > be considered as the scrum team figures out how to most effectively build
                  > > the software functionality the PO deems most desirable (and 'pays' for) for
                  > > any given sprint.
                  > >
                  > > So, I'd first recommend that:
                  > >
                  > > > "Is it possible, as a scrumteam, to plan in our own stories,
                  > > > even if the product owner disagrees?"
                  > >
                  > > is a moot point for this forum. The implicit answer is "Of course it's
                  > > possible" from a Scrum philosophy perspective.
                  > >
                  > > But I suspect that's not the intent of the question. You cannot get
                  > > "advice" from this group that will enable you to bypass your own internal
                  > > politics. It seems to me you're looking for permission to do something your
                  > > team deems appropriate for more effective software creation but haven't
                  > > gotten the 'go-ahead' to do it for whatever reason (including not having
                  > > asked yet).
                  > >
                  > > If your workday is governed solely by what backlog items exist in your
                  > > sprint backlog, then this is really a question for your PO. Bottom line, you
                  > > need to convince the PO that taking the time (possibly incrementally over a
                  > > few sprints) to make adjustments to your team's development process can have
                  > > positive benefits for the PO's investment to "allow" it to happen.
                  > >
                  > > Of course, there is the philosophy of self-organization in Scrum. If your
                  > > organization supports self-organization deeply enough, I would suggest you
                  > > need not get permission - that the team decides what workday efforts are
                  > > appropriate to complete a sprint once the sprint backlog has been decided.
                  > > So, you could simply have the team agree to fewer backlog items and roll the
                  > > process improvement into the development process (again, possibly
                  > > incrementally) until complete. Your team velocity may take a hit, but then
                  > > again, so does the speed of a sailboat as you adjust your sails to take
                  > > better advantage of atmospheric conditions.
                  > >
                  > > Bill Berger
                  > >
                  > >
                  > >
                  >
                • davenicolette
                  ... [...] ... +1. It s the PO s decision, and if the team believe it s an real issue they can provide information about the impact of the issue so the PO can
                  Message 8 of 11 , Apr 1, 2009
                  • 0 Attachment
                    --- In scrumdevelopment@yahoogroups.com, "William Berger" <Bill.Berger@...> wrote:
                    >
                    [...]
                    > Bottom line, you need to convince the PO that taking the time (possibly incrementally over a few sprints) to make adjustments to your team's development process can have positive benefits for the PO's investment to "allow" it to happen.

                    +1. It's the PO's decision, and if the team believe it's an real issue they can provide information about the impact of the issue so the PO can make a well-informed decision. He/she may not consider it as important an issue as the team members do. Conversely, he/she might recognize the value of fixing it if properly informed about the impact.

                    Cheers,
                    Dave
                  • Ron Jeffries
                    Hello, Nicolas. On Wednesday, April 1, 2009, at 1:55:24 PM, you ... Seems to me that the PO would notice if the story wasn t done, because the feature would
                    Message 9 of 11 , Apr 1, 2009
                    • 0 Attachment
                      Hello, Nicolas. On Wednesday, April 1, 2009, at 1:55:24 PM, you
                      wrote:

                      > I don't know if it's ok or not, but it happens and that's the main point

                      > We (as a team) defined for this current sprint a task called "rename objects
                      > in the entity framework model". We did this because we have an architecture
                      > team which approves (or not) our code.

                      > If the code is not approved, it won't go to prod => PO will never see all
                      > the business value

                      > ¿Should we eliminate this task? ¿Should we do it silently consuming hours
                      > from other tasks? The PO does not even know it exists and we cannot show it
                      > in a demo because is not something visible.

                      Seems to me that the PO would notice if the story wasn't done,
                      because the feature would never go out. So I think the PO probably
                      could and should value the story.

                      I'm not sure, though, how to make it able to be demonstrated. Maybe
                      someone will think of something.

                      Ron Jeffries
                      www.XProgramming.com
                      www.xprogramming.com/blog
                      Attend our CSM Plus Course!
                      http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                      Knowledge must come through action;
                      you can have no test which is not fanciful,
                      save by trial. -- Sophocles
                    • Roy Morien
                      Having an external architecture team that approves things after the event is inefficient and ineffectyve, except for slowing things down and creating more
                      Message 10 of 11 , Apr 1, 2009
                      • 0 Attachment
                        Having an external architecture team that approves things after the event is inefficient and ineffectyve, except for slowing things down and creating more work. Why aren't they incorporated into the development team and are closelt bound into the collaboration? And what happened to naming standards that people could follow? You have a significant waste, it would seem, by having to rework some stuff.
                         
                        Regards,
                        Roy Morien
                         

                        To: scrumdevelopment@yahoogroups.com
                        From: dnicolet@...
                        Date: Wed, 1 Apr 2009 22:00:02 +0000
                        Subject: [scrumdevelopment] Re: Is it possible as a scrumteam to plan in our own stories in the sprint?

                        Hi Nicolas,

                        Do you think renaming objects in a model would take a significant amount of time? It doesn't *sound* like a big deal, on the surface. If not, then just do it as you work through other items.

                        Did the team know of the naming conventions required to go to prod? If so, then why didn't they follow the required conventions the first time?

                        If the team didn't have that information, then why not? Could be a communication breakdown in the organization, or a lack of collaboration with the architecture team at the start of the project. These are not the PO's problem. Non-functional requirements and organizational standards are the technical team's responsibility.

                        You may not be able to demo this directly, but you can certainly explain the situation to the PO. I'll bet he isn't stupid.

                        Cheers,
                        Dave

                        --- In scrumdevelopment@ yahoogroups. com, Nicolas Mohamed <nicolasmohamed@ ...> wrote:
                        >
                        > I don't know if it's ok or not, but it happens and that's the main point
                        >
                        > We (as a team) defined for this current sprint a task called "rename objects
                        > in the entity framework model". We did this because we have an architecture
                        > team which approves (or not) our code.
                        >
                        > If the code is not approved, it won't go to prod => PO will never see all
                        > the business value
                        >
                        > ¿Should we eliminate this task? ¿Should we do it silently consuming hours
                        > from other tasks? The PO does not even know it exists and we cannot show it
                        > in a demo because is not something visible.
                        >
                        >
                        > Nicolas
                        >
                        > ------------ --------- --------- --------- --------- ----
                        > www.unavisiondistin ta.blogspot. com
                        >
                        >
                        >
                        > On Wed, Apr 1, 2009 at 2:36 PM, William Berger <Bill.Berger@ ...>wrote:
                        >
                        > > Reading this post gives the distinct impression that you perceive there
                        > > are rules to how Scrum works. My understanding is that there are guidelines
                        > > and principles, not hard-n-fast rules. I believe Scrum is not intended to be
                        > > a playbook with rules to run a scrum by, but rather a set of guidelines to
                        > > be considered as the scrum team figures out how to most effectively build
                        > > the software functionality the PO deems most desirable (and 'pays' for) for
                        > > any given sprint.
                        > >
                        > > So, I'd first recommend that:
                        > >
                        > > > "Is it possible, as a scrumteam, to plan in our own stories,
                        > > > even if the product owner disagrees?"
                        > >
                        > > is a moot point for this forum. The implicit answer is "Of course it's
                        > > possible" from a Scrum philosophy perspective.
                        > >
                        > > But I suspect that's not the intent of the question. You cannot get
                        > > "advice" from this group that will enable you to bypass your own internal
                        > > politics. It seems to me you're looking for permission to do something your
                        > > team deems appropriate for more effective software creation but haven't
                        > > gotten the 'go-ahead' to do it for whatever reason (including not having
                        > > asked yet).
                        > >
                        > > If your workday is governed solely by what backlog items exist in your
                        > > sprint backlog, then this is really a question for your PO. Bottom line, you
                        > > need to convince the PO that taking the time (possibly incrementally over a
                        > > few sprints) to make adjustments to your team's development process can have
                        > > positive benefits for the PO's investment to "allow" it to happen.
                        > >
                        > > Of course, there is the philosophy of self-organization in Scrum. If your
                        > > organization supports self-organization deeply enough, I would suggest you
                        > > need not get permission - that the team decides what workday efforts are
                        > > appropriate to complete a sprint once the sprint backlog has been decided.
                        > > So, you could simply have the team agree to fewer backlog items and roll the
                        > > process improvement into the development process (again, possibly
                        > > incrementally) until complete. Your team velocity may take a hit, but then
                        > > again, so does the speed of a sailboat as you adjust your sails to take
                        > > better advantage of atmospheric conditions.
                        > >
                        > > Bill Berger
                        > >
                        > >
                        > >
                        >




                        Click Here View photos of singles in your area
                      Your message has been successfully submitted and would be delivered to recipients shortly.