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.

Tips for PBI Definition
Last Post 09 May 2014 09:54 AM by Wim Heemskerk. 7 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Daniel Bolton
New Member
New Member
Posts:4
Daniel Bolton

--
06 May 2014 10:55 AM
    Generally speaking, if a customer wants a new feature added to the system then the PO needs to break up that new feature into multiple PBIs. What advice do you have for doing this?

    For example, if the new feature had a UI, would you recommend that the first PBI be to create the UI and populate it with dummy data? Then the next couple PBI might be to work on some aspect of the backend to provide real data to that prototyped UI.
    Chee-Hong Hsia
    New Member
    New Member
    Posts:71
    Chee-Hong Hsia

    --
    07 May 2014 02:06 AM

    Posted By Dan Bolton on 06 May 2014 11:55 AM
    Generally speaking, if a customer wants a new feature added to the system then the PO needs to break up that new feature into multiple PBIs. What advice do you have for doing this?

    For example, if the new feature had a UI, would you recommend that the first PBI be to create the UI and populate it with dummy data? Then the next couple PBI might be to work on some aspect of the backend to provide real data to that prototyped UI.

    Hi Dan,

    Here an interesting artical by Christiaan Verwijs regarding splitting up PBI's. Especially the first part "Horizontal vs Vertical slicing".

    Cheers, Chee-Hong
    Chee-Hong Hsia
    New Member
    New Member
    Posts:71
    Chee-Hong Hsia

    --
    07 May 2014 02:06 AM
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig  Harsch

    --
    07 May 2014 03:53 AM
    Hi Dan,
    what you describe is an anti-pattern.
    The Product Owner should focus on incremental delivery of value, and dummy data does not deliver much value.
    Try to find the minimal marketable feature. It should be a slice through all levels: UI, Backend, Database. It is easy to say and difficult to master.
    Himadri Bhattacharya
    New Member
    New Member
    Posts:18
    Himadri Bhattacharya

    --
    07 May 2014 04:27 AM
    Dan - the example you give is not a releasable feature and hence does not meet the definition of scrum. You need to either refine the PBI further or increase the sprint time to achieve your goal. You may even think of increasing the number of scrum team to achieve this but whatever you do the final outcome should be a releasable product.

    the PO needs to break up that new feature into multiple PBIs


    The PO does not do this on his own - he along with the Development team will try and break up the new feature into multiple PBIs. This is an on-going process and keeps getting refined as more information is made available or comes to light.

    What advice do you have for doing this?

    1) Spend at least 10% of the sprint time to refine the PBIs
    2) Take dependencies into account (both business and software) to prioritize work
    3) Concentrate on the question 'what does the customer want?'
    4) Try and frame the PBI into 'As a [role] I would like to [action] so that I can [outcome/result]'

    Scrum is an iterative and incremental process - make the most of the flexible approach and keep refining your work.

    Olivier Ledru
    Basic Member
    Basic Member
    Posts:206
    Olivier Ledru

    --
    07 May 2014 04:23 PM
    You should google for "user story splitting patterns". None of them proceed layer by layer
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1451
    Ian Mitchell

    --
    09 May 2014 08:23 AM
    Hims and Ludwig are right. The PO should focus on the incremental release of actual value. When it comes to the elicitation of product backlog items, the whole team should be involved...not just the PO. Mike Cohn blogged about this latter point on Tuesday: http://www.mountaingoatsoftware.com...ry-writing

    The PO does have the specific responsibility of organizing the Product Backlog so that the formulation of useful and achievable Sprint Goals is facilitated during Sprint Planning.

    Wim Heemskerk
    New Member
    New Member
    Posts:2
    Wim Heemskerk

    --
    09 May 2014 09:54 AM
    if the new feature had a UI, would you recommend that the first PBI be to create the UI and populate it with dummy data?

    Only if you badly need feedback on that UI.

    The other posters have told why the answer to that is generally: "No". But on a few occasions, it might be: "Yes". It depends on where the risk is, where the biggest unknowns are; if you're not at all sure how the UI should work from the user's perspective, or whether your users will want the feature at all, you might want to create the UI first, get feedback on it (from a user panel for example) and iterate on that.

    This is a bit on the outskirts of software development with Scrum. If you happen to find yourself in situations like that, I suggest you look into Lean Startup and Eric Ries' book by that title.


    You are not authorized to post a reply.


    Feedback