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

56302Re: [scrumdevelopment] Requirement communication between dev and PO

Expand Messages
  • changjiang1124@gmail.com
    Nov 28, 2012
      Thanks for all your replies. 

      Our PO does like to interact with Dev, but he would miss some details, some of which are important, some are not. Dev doesn't foresee these details until they begin to develop these modules. 
      I am the SM, also dev manager. We work together. Maybe I heard from dev too much, but they are just sick of too many things must ask first,  rather than according to documentations, which could make dev progress more smooth.

      Specification may do a lot of help. I will look into this and try to figure out a suitable one. Right now, PO seems mix stories and specifications together. 
      About the scale of story, what about different stories share the same struct? Is this the time to tell "epic"?
      And you seems to talk about let dev have some product sense to make the decisions, but how to handle different persons have different options to product? 

      Best regards
      Chang, Jiang

      On Nov 28, 2012, at 10:52 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:



      +1 to Kurt's and Michael's answers.

      From your description, it sounds like your PO is not interacting with your Dev Team enough to discuss details, and possibly your "stories" are too big. 

      How often does your PO interact with your Dev Team?  What is your role on the team?  Is your whole Scrum team co-located?
      Charles Bradley

      From: Kurt Häusler <kurt.haeusler@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Wednesday, November 28, 2012 6:19 AM
      Subject: Re: [scrumdevelopment] Requirement communication between dev and PO

      Have a look at Specification by Example.

      Also, if there is enough details for a story that a whole document could be written, the story is probably too big, and should be split.

      Branches of a users operation: story is too big. Make each branch a story.
      Sources of data: that is possibly part of the solution rather than the problem. It sounds a bit too technical for a product owner to worry about. He should just say what the user wants and why, and the developers should decide the technical aspects.
      Consequences of actions: This sounds like acceptance criteria. Specification by Example can help here too.

      And don't forget, a story is only a place holder for communication that should take place during the sprint. Maybe what you consider too much, is just the right amount.

      Although, if the PO is a bottleneck, and developers cannot work until the PO is free to answer their questions that could be an issue worth analyzing. In this case I would empower the developers to simply do what makes sense, and what to see if any adjustments are needed in future sprints.

      On Wed, Nov 28, 2012 at 10:23 AM, changjiang1124@... <changjiang1124@...> wrote:
      Hi there:

      I believe this is a cliche topic, but I haven't found anything satisfactory. 

      PO can tell the main function via user stories, but when it comes to dev, it's not enough. Does PO have to write another document to tell the details? Like the branches of user's operation, sources of data that's showed on the pages, the consequences of actions, and etc. 

      If you do so, it would slow down the progress, especially the starts. If not, how can POs make the stories clear, by clear, I mean avoid too much communication during the dev progress,  not mention some of the results of communication would cause big trouble to the code. 

      Do you have some best-practise to share? Like some template or something?

      Really hope hear your thoughts. 

      Best regards
      Chang, Jiang

    • Show all 21 messages in this topic