Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Priority within sprint
Last Post 23 Jun 2014 06:39 PM by VS Chandra Mouli Seelaboyina. 5 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
VS Chandra Mouli Seelaboyina
New Member
New Member
Posts:27
VS Chandra Mouli Seelaboyina

--
20 Jun 2014 09:14 PM
    Hi All,

    Here is a situation that I am facing in a scrum team. I m a new member of scrum team. The practices are totally confusing.


    During sprint planning they are assigning person who is going to work on based on his or her available capacity.
    And forcing the person to provide task break up and hours to the task item. he is the sole responsible person to finish the task.

    And team will get suggestions to prioritize the sprint backlogs what to do first what next from scrum master.


    What I feel is there should not be any priority with in sprint backlogs. all are equally important, they should be delivered by the end of sprint based on the Sprint goal & DoD as shippable features.

    Task break up should happen but who works on that should be decided by the team as whole, its their own business and there should not be any external influence on that.

    Any person can work on any task based on his skill, Then only the knowledge will flow freely among the team.

    Please share your ideas.

    Thanks



    Chee-Hong Hsia
    New Member
    New Member
    Posts:73
    Chee-Hong Hsia

    --
    22 Jun 2014 02:18 AM

    During sprint planning they are assigning person who is going to work on based on his or her available capacity. And forcing the person to provide task break up and hours to the task item. he is the sole responsible person to finish the task.

    Why not get the entire team involved in this process? I would advise the team to apply bottom-up intelligence and utilize the knowledge of the team instead of constraining the team with the knowledge of 1 person.
    Furthermore, it's a bad practise to make 1 person sole responsible to finish a story. If person A is sole responsible for an item, why would I care then? making 1 person sole responsible destroys your team to become self-organized.


    What I feel is there should not be any priority with in sprint backlogs. all are equally important, they should be delivered by the end of sprint based on the Sprint goal & DoD as shippable features.

    Ideally what the team has initial commit they should strive to finish it. So with that mindset yes priority within a sprint backlog shouldn't exist because at the end of the sprint ALL needs to be done. But what if (and this will happen) 1 story is bigger than what the team has initially forecast? What if the team forecast to finish 10 stories and eventually finished 5?
    If I was the Product Owner I would be upset and even MORE upset it these 5 items were the 5 from the lower half... The idea is to always work on items which has the highest business value for the PO so within a sprint backlog there will always be a priority present.







    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1538
    Ian Mitchell

    --
    22 Jun 2014 10:28 AM
    > During sprint planning they are assigning person who is going to work on based
    > on his or her available capacity. And forcing the person to provide task break up
    > and hours to the task item. he is the sole responsible person to finish the task.

    Who are "they", these people who are doing this "forcing"? Is it the Development Team themselves? Coercion of a team member is not the same as self-organization. Are there interpersonal team issues here?

    > What I feel is there should not be any priority with in sprint backlogs. all are
    > equally important, they should be delivered by the end of sprint based on the
    > Sprint goal & DoD as shippable features.

    It's the Sprint Goal that's important, so you could turn this around. All items in a Sprint Backlog are all equally *unimportant*.

    The Development Team wholly own their Sprint Backlog. As such, it is up to them to decide which (if any) priorities should apply to Sprint Backlog items. These priorities could - but might not necessarily - relate to the delivery of business value. This is because in Scrum the Product Owner can expect to receive an increment by the end of the Sprint, but has no right to expect intermediate deliverables. In other words the PO has no right to set Sprint Backlog priorities in order to receive a deliverable part way through a Sprint. It is arguably possible for the PO to *negotiate* such an arrangement with the team, but they are under no obligation to support a request of this nature.

    Sprint Backlog priorities can also be technical. For example, suppose we have the Sprint Goal of allowing registered users to log in to a site. The Development Team might reasonably decide to action any "registration" user stories before those for logging in. Those Sprint Backlog items are therefore prioritized. That could be perfectly reasonable behavior on the part of a self-organizing team.
    Bartosz Janowski
    New Member
    New Member
    Posts:20
    Bartosz Janowski

    --
    22 Jun 2014 11:29 AM
    Did you get any explanation why the team forces its members to get particular task?

    Each member should decide what to do. It's called pull mechanism and it's important part of Scrum. What you describe is push in fact.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:409
    Charles Bradley

    --
    23 Jun 2014 07:24 AM
    +1 to all of the above. Sounds like to me a team who thinks they are doing Scrum but is not even close. Probably could use some Scrum training or refresher training.
    VS Chandra Mouli Seelaboyina
    New Member
    New Member
    Posts:27
    VS Chandra Mouli Seelaboyina

    --
    23 Jun 2014 06:39 PM
    I do agree to all your opinions. Thanks a lot. The reason why the team is practicing a process which sounds like scrum but not is SM is not trained, still living in the people management era. Managing people not process.
    You are not authorized to post a reply.


    Feedback