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.

The Story Map
Last Post 03 Mar 2014 09:54 AM by Ian Mitchell. 2 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Justin Todd
New Member
New Member
Posts:48
Justin Todd

--
03 Mar 2014 08:11 AM
    HI,

    Does anyone have any strong feelings about this "idea"?

    http://www.agileproductdesign.com/b...cklog.html

    Thanks,
    Justin
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig  Harsch

    --
    03 Mar 2014 09:18 AM
    Hi Justin,
    yes I do use a Story Map very similar to the one displayed there and we made very good experience with it.
    The second dimension gives you a better overview of a big product than an ordered list, and the "hardware solution" supports discussions with stakeholders more than an electronic tool.
    Before each sprint planning, the product owner selects some of the top items and orders them. The resulting list with defined priority is the part of Product Backlog relevant for planning.
    Best, Ludwig
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    03 Mar 2014 09:54 AM
    > When it comes time to prioritize stories, I don't prioritize the backbone. It just "is." I do prioritize the ribs...

    A variant of this principle is the MoSCoW prioritization of user stories where each epic may be compulsory, but only some of the constituent leaf node stories will be. This is how the "everything is a must" problem can be resolved. Once you get stories that meet the INVEST criteria, less than half are likely to be mandatory and contribute to the MVP.

    Some other observations:

    - In Scrum, Product Backlog Items (PBI's) have both order and value. The composition of a "one dimensional" backlog can therefore be more nuanced than the article implies
    - It is potentially wasteful to define the ribs of a walking skeleton application before those stories or tasks are ready to be progressed. The added detail may depreciate in value, as it will no longer be current at the time of actioning. Giving clear order to a backlog allows such details to be elucidated in a more just-in-time manner.
    - You don't want pull to be exerted on an item that has not been given business priority for actioning. To do so will increase WIP and lengthen the lead time. This is why a Product Owner is jointly responsible for ROI and for giving order to the Product Backlog.
    You are not authorized to post a reply.


    Feedback