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

Re: Requirement communication between dev and PO

Expand Messages
  • gregc
    Jiang, And what are his current responsibilities? Thanks, -greg
    Message 1 of 21 , Dec 3, 2012
    • 0 Attachment
      Jiang,

      And what are his current responsibilities?

      Thanks,

      -greg



      --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
      >
      > Hi Greg:
      >
      > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
      >
      >
      > Best regards
      > Chang, Jiang
      >
      >
      >
      > On Dec 1, 2012, at 1:16 PM, gregc <greg@...> wrote:
      >
      > >
      > > Jiang,
      > >
      > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
      > >
      > > -greg
      > >
      > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
      > > >
      > > > Jiang,
      > > >
      > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
      > > > >
      > > > >
      > > > > Thanks for all your replies.
      > > > >
      > > > > Charles:
      > > > > 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.
      > > >
      > > > It's all about the conversations. Take a look at
      > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
      > > > to get some ideas about how these conversations can help.
      > > >
      > > > - George
      > > >
      > > > --
      > > > ----------------------------------------------------------
      > > > * George Dinwiddie * http://blog.gdinwiddie.com
      > > > Software Development http://www.idiacomputing.com
      > > > Consultant and Coach http://www.agilemaryland.org
      > > > ----------------------------------------------------------
      > > >
      > >
      > >
      >
    • changjiang1124@gmail.com
      Greg: He is responsible for all the product of our company, like a VP or a product director. Best regards Chang, Jiang
      Message 2 of 21 , Dec 3, 2012
      • 0 Attachment
        Greg:

        He is responsible for all the product of our company, like a VP or a product director.


        Best regards
        Chang, Jiang



        On Dec 4, 2012, at 2:15 PM, "gregc" <greg@...> wrote:

         

        Jiang,

        And what are his current responsibilities?

        Thanks,

        -greg

        --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
        >
        > Hi Greg:
        >
        > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
        >
        >
        > Best regards
        > Chang, Jiang
        >
        >
        >
        > On Dec 1, 2012, at 1:16 PM, gregc <greg@...> wrote:
        >
        > >
        > > Jiang,
        > >
        > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
        > >
        > > -greg
        > >
        > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
        > > >
        > > > Jiang,
        > > >
        > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
        > > > >
        > > > >
        > > > > Thanks for all your replies.
        > > > >
        > > > > Charles:
        > > > > 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.
        > > >
        > > > It's all about the conversations. Take a look at
        > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
        > > > to get some ideas about how these conversations can help.
        > > >
        > > > - George
        > > >
        > > > --
        > > > ----------------------------------------------------------
        > > > * George Dinwiddie * http://blog.gdinwiddie.com
        > > > Software Development http://www.idiacomputing.com
        > > > Consultant and Coach http://www.agilemaryland.org
        > > > ----------------------------------------------------------
        > > >
        > >
        > >
        >


      • Gopinath KS
        Hi, This need to be taken care in the Sprint planning meeting. Writing another document isn t right way in my experience. Regards, Gopinath On Wed, Nov 28,
        Message 3 of 21 , Dec 5, 2012
        • 0 Attachment
          Hi,
              This need to be taken care in the Sprint planning meeting. Writing another document isn't right way in my experience.
           
          Regards,
          Gopinath

          On Wed, Nov 28, 2012 at 2:53 PM, 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. 
          Thanks


          Best regards
          Chang, Jiang




        • gregc
          Jiang, It s very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what
          Message 4 of 21 , Dec 5, 2012
          • 0 Attachment
            Jiang,
            It's very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what being "responsible" for the product really means as far as the activities the PO owns. But for now, I'll attempt to layout a simple model and tell you what I've heard and you can let me know if this model applies and if my hypothesis on where the problem might lay has merit.

            In one of the simpler views of the world, new product development has 3 phases that need to be passed through. This is true of waterfall or agile: these only differ in the batch size accepted into each phase. The phases are Define --> Design --> Build.

            This step in the middle, Design, is really important. It is where we match the problem or need to a solution. In definition we get a sense of what a customer is trying to accomplish, how they think about success, and their impediments to realizing that. Definition is about needs. It requires research, VOC, ethnography, observation. In the design step, it's about analysis, a feature or set of features begin to emerge to satisfy the need. This takes analysts skills and a deep understanding of workflows, data elements, rules. There's also user experience, understanding the interaction design, visual design, information architecture, and actual content that needs to be presented and which data elements can be manipulated and how, etc. and you need technical architecture skill describe how the design will be implemented. Now it sounds to me like

            1) your developers are well equipped to build and well equipped to handle the technical architecture.
            2) your PO can define the customer's need (although I'm not certain of this.)
            3) you may have a gap in design where some or all of the major design tasks are not being handled by anyone. Or no one is willing to own them so they are being handled in an adhoc fashion. This might be an issue of individuals not believing it is their responsibility or a missing skill set within the team.

            Let me know if this is on target or not.

            -greg


            --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
            >
            > Greg:
            >
            > He is responsible for all the product of our company, like a VP or a product director.
            >
            >
            > Best regards
            > Chang, Jiang
            >
            >
            >
            > On Dec 4, 2012, at 2:15 PM, "gregc" <greg@...> wrote:
            >
            > > Jiang,
            > >
            > > And what are his current responsibilities?
            > >
            > > Thanks,
            > >
            > > -greg
            > >
            > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
            > > >
            > > > Hi Greg:
            > > >
            > > > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
            > > >
            > > >
            > > > Best regards
            > > > Chang, Jiang
            > > >
            > > >
            > > >
            > > > On Dec 1, 2012, at 1:16 PM, gregc <greg@> wrote:
            > > >
            > > > >
            > > > > Jiang,
            > > > >
            > > > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
            > > > >
            > > > > -greg
            > > > >
            > > > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
            > > > > >
            > > > > > Jiang,
            > > > > >
            > > > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
            > > > > > >
            > > > > > >
            > > > > > > Thanks for all your replies.
            > > > > > >
            > > > > > > Charles:
            > > > > > > 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.
            > > > > >
            > > > > > It's all about the conversations. Take a look at
            > > > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
            > > > > > to get some ideas about how these conversations can help.
            > > > > >
            > > > > > - George
            > > > > >
            > > > > > --
            > > > > > ----------------------------------------------------------
            > > > > > * George Dinwiddie * http://blog.gdinwiddie.com
            > > > > > Software Development http://www.idiacomputing.com
            > > > > > Consultant and Coach http://www.agilemaryland.org
            > > > > > ----------------------------------------------------------
            > > > > >
            > > > >
            > > > >
            > > >
            > >
            > >
            >
          • changjiang1124@gmail.com
            Greg: Exactly!! I almost get your conclusion by finishing reading the first 2 paragraphs. This is like a grey zone. Both side (PO and dev) would think that s
            Message 5 of 21 , Dec 6, 2012
            • 0 Attachment
              Greg:

              Exactly!! I almost get your conclusion by finishing reading the first 2 paragraphs. 

              This is like a grey zone. Both side (PO and dev) would think that's the other's problem. Right now, it seems kinda a solution by gathering PO and dev (maybe just some of them) together to discuss the details, inspired by backlog grooming. The whole team could need some time to get used to this meeting and find the routine.

              Could I get some advices from you? 


              Best regards
              Chang, Jiang



              On Dec 6, 2012, at 3:55 PM, "gregc" <greg@...> wrote:

               

              Jiang,
              It's very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what being "responsible" for the product really means as far as the activities the PO owns. But for now, I'll attempt to layout a simple model and tell you what I've heard and you can let me know if this model applies and if my hypothesis on where the problem might lay has merit.

              In one of the simpler views of the world, new product development has 3 phases that need to be passed through. This is true of waterfall or agile: these only differ in the batch size accepted into each phase. The phases are Define --> Design --> Build.

              This step in the middle, Design, is really important. It is where we match the problem or need to a solution. In definition we get a sense of what a customer is trying to accomplish, how they think about success, and their impediments to realizing that. Definition is about needs. It requires research, VOC, ethnography, observation. In the design step, it's about analysis, a feature or set of features begin to emerge to satisfy the need. This takes analysts skills and a deep understanding of workflows, data elements, rules. There's also user experience, understanding the interaction design, visual design, information architecture, and actual content that needs to be presented and which data elements can be manipulated and how, etc. and you need technical architecture skill describe how the design will be implemented. Now it sounds to me like

              1) your developers are well equipped to build and well equipped to handle the technical architecture.
              2) your PO can define the customer's need (although I'm not certain of this.)
              3) you may have a gap in design where some or all of the major design tasks are not being handled by anyone. Or no one is willing to own them so they are being handled in an adhoc fashion. This might be an issue of individuals not believing it is their responsibility or a missing skill set within the team.

              Let me know if this is on target or not.

              -greg

              --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
              >
              > Greg:
              >
              > He is responsible for all the product of our company, like a VP or a product director.
              >
              >
              > Best regards
              > Chang, Jiang
              >
              >
              >
              > On Dec 4, 2012, at 2:15 PM, "gregc" <greg@...> wrote:
              >
              > > Jiang,
              > >
              > > And what are his current responsibilities?
              > >
              > > Thanks,
              > >
              > > -greg
              > >
              > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
              > > >
              > > > Hi Greg:
              > > >
              > > > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
              > > >
              > > >
              > > > Best regards
              > > > Chang, Jiang
              > > >
              > > >
              > > >
              > > > On Dec 1, 2012, at 1:16 PM, gregc <greg@> wrote:
              > > >
              > > > >
              > > > > Jiang,
              > > > >
              > > > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
              > > > >
              > > > > -greg
              > > > >
              > > > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
              > > > > >
              > > > > > Jiang,
              > > > > >
              > > > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
              > > > > > >
              > > > > > >
              > > > > > > Thanks for all your replies.
              > > > > > >
              > > > > > > Charles:
              > > > > > > 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.
              > > > > >
              > > > > > It's all about the conversations. Take a look at
              > > > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
              > > > > > to get some ideas about how these conversations can help.
              > > > > >
              > > > > > - George
              > > > > >
              > > > > > --
              > > > > > ----------------------------------------------------------
              > > > > > * George Dinwiddie * http://blog.gdinwiddie.com
              > > > > > Software Development http://www.idiacomputing.com
              > > > > > Consultant and Coach http://www.agilemaryland.org
              > > > > > ----------------------------------------------------------
              > > > > >
              > > > >
              > > > >
              > > >
              > >
              > >
              >


            • Charles Bradley - Professional Scrum Trai
              Jiang, For the case of recording details, it s good to record that minimum that could *possibly work.*  If you re finding out that details are missed *and*
              Message 6 of 21 , Dec 6, 2012
              • 0 Attachment
                Jiang,

                For the case of recording details, it's good to record that minimum that could *possibly work.*  If you're finding out that details are missed *and* are not easily "re-discovered" through conversation, then you can decide to record more detail.  Along those lines, you may find this presentation helpful: 
                http://www.scrumcrazy.com/Presentation+-+Story+Testing+Patterns

                For the case of "changing requirements", my general view is that small changes/clarifications are fine so long as they are not totally disruptive.  For more on that, see:
                http://www.scrumcrazy.com/One+Way+to+Handle+Mid+Sprint+Scope+Changes+in+Scrum

                Hope this helps!

                -------
                Charles Bradley
                Scrum Coach-in-Chief
                ScrumCrazy.com




                From: "changjiang1124@..." <changjiang1124@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Sunday, December 2, 2012 9:34 PM
                Subject: Re: [scrumdevelopment] Requirement communication between dev and PO



                Hi Charles:

                I know we are not psychics, I just want to figure out what are acceptable and what are not, to make our team more efficient. 

                These "things" are more like details and consistencies. Like details and constraints of financial processes, UI design does some confusions of revealing requirement, or sometimes after discussions or demos, PO thinks the requirement he stated at the kick-off doesn't work, so he changes. 

                You made the point of backlog grooming, we should try harder on it. 


                Best regards
                Chang, Jiang



                On Nov 30, 2012, at 6:26 AM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:

                 

                Jiang,

                >Charles: 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.

                This sounds like a perfectly functioning software development team.  Software development is complex, and we are not psychics... things come up that we didn't foresee,which is why we control this risk via Scrum.  If your team is co-located and the PO likes to interact with Dev, then I don't see a need for more formal specs.  Now, if the details are or domain are highly complex, maybe you do need some low fidelity supplemental info like a wiki.  More likely it is that you need smaller stories.

                At what point does your team realize that they have "missed" something?  Does it happen often enough that you get a lot of complaints about it?  If so, what does your team think will help?  (If they say "more documentation", then ask them why "more verbal communication" won't solve the problem.  It would be very interesting to hear their answer... Also, ask them if there is anything besides document that they think would help.)

                > 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.

                Glad to hear that you are SM, that helps me give you better advice because now I know what your role is.  I hope you are working hard to resist exerting "dev manager" authority and instead let the Dev Team self organize, like a good Scrum Master.  :-)

                Does your team do product backlog grooming once a week?
                 
                -------
                Charles Bradley
                http://www.ScrumCrazy.com




                From: "changjiang1124@..." <changjiang1124@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Wednesday, November 28, 2012 9:27 PM
                Subject: Re: [scrumdevelopment] Requirement communication between dev and PO



                Thanks for all your replies. 

                Charles:
                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.

                @Kurt:
                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:

                 

                Jiang,

                +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
                http://www.ScrumCrazy.com




                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. 
                Thanks


                Best regards
                Chang, Jiang




















              • gregc
                Jiang, Scrum is good at exposing problems. So it s been successful in that regard. And now that the problem is defined, let s look at ways to address it.
                Message 7 of 21 , Dec 6, 2012
                • 0 Attachment
                  Jiang,

                  Scrum is good at exposing problems. So it's been successful in that regard. And now that the problem is defined, let's look at ways to address it. There is a gap in design and that gap needs to be closed. Part of that can be closed through good collaboration around the story. The story has the three elements: the actual story, the conversation around it, and the joint development of the satisfaction criteria. This should be part of your definition of "ready" before a story can be accepted into a sprint. I'm confident if you do this, things will improve but I am not convinced your problem will be solved.

                  A first step would be to lay out the design tasks (which I think for your team means detailed description of functionality, mock-ups, etc.) that aren't being adequately covered today and have the dev team and PO come to some understanding of who is responsible for each of these and how those tasks are going to get done. I think the Team also has to decide if they have the necessary skill set or if a skills gap needs to be filled. Out of this, at least the problem can be recognized, internalized, and the team can develop a plan to address it.

                  The conundrum as I see it is the dev team doesn't want to own design. Their passion is for building, not designing. Yet the PO, even if he wants to own design, is unlikely to be able to deliver. Your PO is the VP of Product. And a VP of product has a lot of market facing responsibilities that will prevent him from being able to spend the time necessary to meet the dev team's expectations and needs. I don't think your core problem is with your scrum practices but rather with how you're organized.

                  I don't know if this is possible for your company, but my first reaction is that you need a new PO. One who who has more of an analyst skill set. And then I would divide the VP of Product (i.e. product management) and PO responsibilities along the following lines:

                  1) Your VP of Product will focus on understanding the market, VOC, competitive analysis, business strategy, product positioning and the strategic roadmap.

                  2) The PO will focus on being the expert on the user and everything about the job the user is trying to accomplish (yes, this means the PO will need to be comfortable spending time with users. The knowledge the PO needs to succeed does not come second hand.) The PO will have responsibility, while still collaborating with the team, for feature definition (using stories as the main artifact with supplemental documents like mock-ups, business logic, and task flows as needed), usability, scoping, and the product roadmap.

                  Once again, diagnosing via email is tough. Let me know if I've misinterpreted your situation. Also, it sounds like you're a relatively young company. If your company has not yet achieved product-market fit and a scalable business model, I would organize slightly differently.

                  Best,

                  -greg

                  --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
                  >
                  > Greg:
                  >
                  > Exactly!! I almost get your conclusion by finishing reading the first 2 paragraphs.
                  >
                  > This is like a grey zone. Both side (PO and dev) would think that's the other's problem. Right now, it seems kinda a solution by gathering PO and dev (maybe just some of them) together to discuss the details, inspired by backlog grooming. The whole team could need some time to get used to this meeting and find the routine.
                  >
                  > Could I get some advices from you?
                  >
                  >
                  > Best regards
                  > Chang, Jiang
                  >
                  >
                  >
                  > On Dec 6, 2012, at 3:55 PM, "gregc" <greg@...> wrote:
                  >
                  > > Jiang,
                  > > It's very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what being "responsible" for the product really means as far as the activities the PO owns. But for now, I'll attempt to layout a simple model and tell you what I've heard and you can let me know if this model applies and if my hypothesis on where the problem might lay has merit.
                  > >
                  > > In one of the simpler views of the world, new product development has 3 phases that need to be passed through. This is true of waterfall or agile: these only differ in the batch size accepted into each phase. The phases are Define --> Design --> Build.
                  > >
                  > > This step in the middle, Design, is really important. It is where we match the problem or need to a solution. In definition we get a sense of what a customer is trying to accomplish, how they think about success, and their impediments to realizing that. Definition is about needs. It requires research, VOC, ethnography, observation. In the design step, it's about analysis, a feature or set of features begin to emerge to satisfy the need. This takes analysts skills and a deep understanding of workflows, data elements, rules. There's also user experience, understanding the interaction design, visual design, information architecture, and actual content that needs to be presented and which data elements can be manipulated and how, etc. and you need technical architecture skill describe how the design will be implemented. Now it sounds to me like
                  > >
                  > > 1) your developers are well equipped to build and well equipped to handle the technical architecture.
                  > > 2) your PO can define the customer's need (although I'm not certain of this.)
                  > > 3) you may have a gap in design where some or all of the major design tasks are not being handled by anyone. Or no one is willing to own them so they are being handled in an adhoc fashion. This might be an issue of individuals not believing it is their responsibility or a missing skill set within the team.
                  > >
                  > > Let me know if this is on target or not.
                  > >
                  > > -greg
                  > >
                  > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
                  > > >
                  > > > Greg:
                  > > >
                  > > > He is responsible for all the product of our company, like a VP or a product director.
                  > > >
                  > > >
                  > > > Best regards
                  > > > Chang, Jiang
                  > > >
                  > > >
                  > > >
                  > > > On Dec 4, 2012, at 2:15 PM, "gregc" <greg@> wrote:
                  > > >
                  > > > > Jiang,
                  > > > >
                  > > > > And what are his current responsibilities?
                  > > > >
                  > > > > Thanks,
                  > > > >
                  > > > > -greg
                  > > > >
                  > > > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
                  > > > > >
                  > > > > > Hi Greg:
                  > > > > >
                  > > > > > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
                  > > > > >
                  > > > > >
                  > > > > > Best regards
                  > > > > > Chang, Jiang
                  > > > > >
                  > > > > >
                  > > > > >
                  > > > > > On Dec 1, 2012, at 1:16 PM, gregc <greg@> wrote:
                  > > > > >
                  > > > > > >
                  > > > > > > Jiang,
                  > > > > > >
                  > > > > > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
                  > > > > > >
                  > > > > > > -greg
                  > > > > > >
                  > > > > > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
                  > > > > > > >
                  > > > > > > > Jiang,
                  > > > > > > >
                  > > > > > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
                  > > > > > > > >
                  > > > > > > > >
                  > > > > > > > > Thanks for all your replies.
                  > > > > > > > >
                  > > > > > > > > Charles:
                  > > > > > > > > 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.
                  > > > > > > >
                  > > > > > > > It's all about the conversations. Take a look at
                  > > > > > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
                  > > > > > > > to get some ideas about how these conversations can help.
                  > > > > > > >
                  > > > > > > > - George
                  > > > > > > >
                  > > > > > > > --
                  > > > > > > > ----------------------------------------------------------
                  > > > > > > > * George Dinwiddie * http://blog.gdinwiddie.com
                  > > > > > > > Software Development http://www.idiacomputing.com
                  > > > > > > > Consultant and Coach http://www.agilemaryland.org
                  > > > > > > > ----------------------------------------------------------
                  > > > > > > >
                  > > > > > >
                  > > > > > >
                  > > > > >
                  > > > >
                  > > > >
                  > > >
                  > >
                  > >
                  >
                • changjiang1124@gmail.com
                  Hi Greg: All your thoughts on my situation are right, include we are a young company. Thanks for your detailed reply, I really got lots of ideas from it. We
                  Message 8 of 21 , Dec 7, 2012
                  • 0 Attachment
                    Hi Greg:

                    All your thoughts  on my situation are right, include we are a young company.

                    Thanks for your detailed reply, I really got lots of ideas from it. 
                    We do need a new PO, coz right now we just have 1 PO that he are managing too many things. Since it's hard to find a suitable candidate, even I could be a half PO, which I don't know whether this is the right thing.

                    I still have one thought about this under the current circumstance, I put my QA to write test items just after the kick-off, since they need to think through the details, they can come out really nice questions about the stories to help them get designed at the early stage of building.

                    Can this be a solution, or there maybe exist some potential risks? 


                    Best regards
                    Chang, Jiang



                    On Dec 7, 2012, at 2:44 PM, "gregc" <greg@...> wrote:

                     

                    Jiang,

                    Scrum is good at exposing problems. So it's been successful in that regard. And now that the problem is defined, let's look at ways to address it. There is a gap in design and that gap needs to be closed. Part of that can be closed through good collaboration around the story. The story has the three elements: the actual story, the conversation around it, and the joint development of the satisfaction criteria. This should be part of your definition of "ready" before a story can be accepted into a sprint. I'm confident if you do this, things will improve but I am not convinced your problem will be solved.

                    A first step would be to lay out the design tasks (which I think for your team means detailed description of functionality, mock-ups, etc.) that aren't being adequately covered today and have the dev team and PO come to some understanding of who is responsible for each of these and how those tasks are going to get done. I think the Team also has to decide if they have the necessary skill set or if a skills gap needs to be filled. Out of this, at least the problem can be recognized, internalized, and the team can develop a plan to address it.

                    The conundrum as I see it is the dev team doesn't want to own design. Their passion is for building, not designing. Yet the PO, even if he wants to own design, is unlikely to be able to deliver. Your PO is the VP of Product. And a VP of product has a lot of market facing responsibilities that will prevent him from being able to spend the time necessary to meet the dev team's expectations and needs. I don't think your core problem is with your scrum practices but rather with how you're organized.

                    I don't know if this is possible for your company, but my first reaction is that you need a new PO. One who who has more of an analyst skill set. And then I would divide the VP of Product (i.e. product management) and PO responsibilities along the following lines:

                    1) Your VP of Product will focus on understanding the market, VOC, competitive analysis, business strategy, product positioning and the strategic roadmap.

                    2) The PO will focus on being the expert on the user and everything about the job the user is trying to accomplish (yes, this means the PO will need to be comfortable spending time with users. The knowledge the PO needs to succeed does not come second hand.) The PO will have responsibility, while still collaborating with the team, for feature definition (using stories as the main artifact with supplemental documents like mock-ups, business logic, and task flows as needed), usability, scoping, and the product roadmap.

                    Once again, diagnosing via email is tough. Let me know if I've misinterpreted your situation. Also, it sounds like you're a relatively young company. If your company has not yet achieved product-market fit and a scalable business model, I would organize slightly differently.

                    Best,

                    -greg

                    --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
                    >
                    > Greg:
                    >
                    > Exactly!! I almost get your conclusion by finishing reading the first 2 paragraphs.
                    >
                    > This is like a grey zone. Both side (PO and dev) would think that's the other's problem. Right now, it seems kinda a solution by gathering PO and dev (maybe just some of them) together to discuss the details, inspired by backlog grooming. The whole team could need some time to get used to this meeting and find the routine.
                    >
                    > Could I get some advices from you?
                    >
                    >
                    > Best regards
                    > Chang, Jiang
                    >
                    >
                    >
                    > On Dec 6, 2012, at 3:55 PM, "gregc" <greg@...> wrote:
                    >
                    > > Jiang,
                    > > It's very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what being "responsible" for the product really means as far as the activities the PO owns. But for now, I'll attempt to layout a simple model and tell you what I've heard and you can let me know if this model applies and if my hypothesis on where the problem might lay has merit.
                    > >
                    > > In one of the simpler views of the world, new product development has 3 phases that need to be passed through. This is true of waterfall or agile: these only differ in the batch size accepted into each phase. The phases are Define --> Design --> Build.
                    > >
                    > > This step in the middle, Design, is really important. It is where we match the problem or need to a solution. In definition we get a sense of what a customer is trying to accomplish, how they think about success, and their impediments to realizing that. Definition is about needs. It requires research, VOC, ethnography, observation. In the design step, it's about analysis, a feature or set of features begin to emerge to satisfy the need. This takes analysts skills and a deep understanding of workflows, data elements, rules. There's also user experience, understanding the interaction design, visual design, information architecture, and actual content that needs to be presented and which data elements can be manipulated and how, etc. and you need technical architecture skill describe how the design will be implemented. Now it sounds to me like
                    > >
                    > > 1) your developers are well equipped to build and well equipped to handle the technical architecture.
                    > > 2) your PO can define the customer's need (although I'm not certain of this.)
                    > > 3) you may have a gap in design where some or all of the major design tasks are not being handled by anyone. Or no one is willing to own them so they are being handled in an adhoc fashion. This might be an issue of individuals not believing it is their responsibility or a missing skill set within the team.
                    > >
                    > > Let me know if this is on target or not.
                    > >
                    > > -greg
                    > >
                    > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
                    > > >
                    > > > Greg:
                    > > >
                    > > > He is responsible for all the product of our company, like a VP or a product director.
                    > > >
                    > > >
                    > > > Best regards
                    > > > Chang, Jiang
                    > > >
                    > > >
                    > > >
                    > > > On Dec 4, 2012, at 2:15 PM, "gregc" <greg@> wrote:
                    > > >
                    > > > > Jiang,
                    > > > >
                    > > > > And what are his current responsibilities?
                    > > > >
                    > > > > Thanks,
                    > > > >
                    > > > > -greg
                    > > > >
                    > > > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
                    > > > > >
                    > > > > > Hi Greg:
                    > > > > >
                    > > > > > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
                    > > > > >
                    > > > > >
                    > > > > > Best regards
                    > > > > > Chang, Jiang
                    > > > > >
                    > > > > >
                    > > > > >
                    > > > > > On Dec 1, 2012, at 1:16 PM, gregc <greg@> wrote:
                    > > > > >
                    > > > > > >
                    > > > > > > Jiang,
                    > > > > > >
                    > > > > > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
                    > > > > > >
                    > > > > > > -greg
                    > > > > > >
                    > > > > > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
                    > > > > > > >
                    > > > > > > > Jiang,
                    > > > > > > >
                    > > > > > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
                    > > > > > > > >
                    > > > > > > > >
                    > > > > > > > > Thanks for all your replies.
                    > > > > > > > >
                    > > > > > > > > Charles:
                    > > > > > > > > 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.
                    > > > > > > >
                    > > > > > > > It's all about the conversations. Take a look at
                    > > > > > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
                    > > > > > > > to get some ideas about how these conversations can help.
                    > > > > > > >
                    > > > > > > > - George
                    > > > > > > >
                    > > > > > > > --
                    > > > > > > > ----------------------------------------------------------
                    > > > > > > > * George Dinwiddie * http://blog.gdinwiddie.com
                    > > > > > > > Software Development http://www.idiacomputing.com
                    > > > > > > > Consultant and Coach http://www.agilemaryland.org
                    > > > > > > > ----------------------------------------------------------
                    > > > > > > >
                    > > > > > >
                    > > > > > >
                    > > > > >
                    > > > >
                    > > > >
                    > > >
                    > >
                    > >
                    >


                  • Markus Gaertner
                    Hi Jiang, for the testers, I recommend that they come up with the following at least during the backlog refinement or grooming meetings: - criteria for
                    Message 9 of 21 , Dec 7, 2012
                    • 0 Attachment
                      Hi Jiang,

                      for the testers, I recommend that they come up with the following at least during the backlog refinement or grooming meetings:
                      - criteria for acceptance of that particular story
                      - exploratory test sessions they would like to run once the story has been implemented
                      - further quality criteria (i.e. non-functional requirements like performance and stability) they think needs to be addressed.

                      This can help to prepare them about which tests are going to be automated, and to close the gaps with non-functional tests which require special tools alongside with a human engaged brain where it is necessary like layout problems, usability, and so on.

                      Best
                      Markus

                      On Fri, Dec 7, 2012 at 10:58 AM, changjiang1124@... <changjiang1124@...> wrote:


                      Hi Greg:

                      All your thoughts  on my situation are right, include we are a young company.

                      Thanks for your detailed reply, I really got lots of ideas from it. 
                      We do need a new PO, coz right now we just have 1 PO that he are managing too many things. Since it's hard to find a suitable candidate, even I could be a half PO, which I don't know whether this is the right thing.

                      I still have one thought about this under the current circumstance, I put my QA to write test items just after the kick-off, since they need to think through the details, they can come out really nice questions about the stories to help them get designed at the early stage of building.

                      Can this be a solution, or there maybe exist some potential risks? 


                      Best regards
                      Chang, Jiang



                      On Dec 7, 2012, at 2:44 PM, "gregc" <greg@...> wrote:

                       

                      Jiang,

                      Scrum is good at exposing problems. So it's been successful in that regard. And now that the problem is defined, let's look at ways to address it. There is a gap in design and that gap needs to be closed. Part of that can be closed through good collaboration around the story. The story has the three elements: the actual story, the conversation around it, and the joint development of the satisfaction criteria. This should be part of your definition of "ready" before a story can be accepted into a sprint. I'm confident if you do this, things will improve but I am not convinced your problem will be solved.

                      A first step would be to lay out the design tasks (which I think for your team means detailed description of functionality, mock-ups, etc.) that aren't being adequately covered today and have the dev team and PO come to some understanding of who is responsible for each of these and how those tasks are going to get done. I think the Team also has to decide if they have the necessary skill set or if a skills gap needs to be filled. Out of this, at least the problem can be recognized, internalized, and the team can develop a plan to address it.

                      The conundrum as I see it is the dev team doesn't want to own design. Their passion is for building, not designing. Yet the PO, even if he wants to own design, is unlikely to be able to deliver. Your PO is the VP of Product. And a VP of product has a lot of market facing responsibilities that will prevent him from being able to spend the time necessary to meet the dev team's expectations and needs. I don't think your core problem is with your scrum practices but rather with how you're organized.

                      I don't know if this is possible for your company, but my first reaction is that you need a new PO. One who who has more of an analyst skill set. And then I would divide the VP of Product (i.e. product management) and PO responsibilities along the following lines:

                      1) Your VP of Product will focus on understanding the market, VOC, competitive analysis, business strategy, product positioning and the strategic roadmap.

                      2) The PO will focus on being the expert on the user and everything about the job the user is trying to accomplish (yes, this means the PO will need to be comfortable spending time with users. The knowledge the PO needs to succeed does not come second hand.) The PO will have responsibility, while still collaborating with the team, for feature definition (using stories as the main artifact with supplemental documents like mock-ups, business logic, and task flows as needed), usability, scoping, and the product roadmap.

                      Once again, diagnosing via email is tough. Let me know if I've misinterpreted your situation. Also, it sounds like you're a relatively young company. If your company has not yet achieved product-market fit and a scalable business model, I would organize slightly differently.

                      Best,

                      -greg

                      --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
                      >
                      > Greg:
                      >
                      > Exactly!! I almost get your conclusion by finishing reading the first 2 paragraphs.
                      >
                      > This is like a grey zone. Both side (PO and dev) would think that's the other's problem. Right now, it seems kinda a solution by gathering PO and dev (maybe just some of them) together to discuss the details, inspired by backlog grooming. The whole team could need some time to get used to this meeting and find the routine.
                      >
                      > Could I get some advices from you?
                      >
                      >
                      > Best regards
                      > Chang, Jiang
                      >
                      >
                      >
                      > On Dec 6, 2012, at 3:55 PM, "gregc" <greg@...> wrote:
                      >
                      > > Jiang,
                      > > It's very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what being "responsible" for the product really means as far as the activities the PO owns. But for now, I'll attempt to layout a simple model and tell you what I've heard and you can let me know if this model applies and if my hypothesis on where the problem might lay has merit.
                      > >
                      > > In one of the simpler views of the world, new product development has 3 phases that need to be passed through. This is true of waterfall or agile: these only differ in the batch size accepted into each phase. The phases are Define --> Design --> Build.
                      > >
                      > > This step in the middle, Design, is really important. It is where we match the problem or need to a solution. In definition we get a sense of what a customer is trying to accomplish, how they think about success, and their impediments to realizing that. Definition is about needs. It requires research, VOC, ethnography, observation. In the design step, it's about analysis, a feature or set of features begin to emerge to satisfy the need. This takes analysts skills and a deep understanding of workflows, data elements, rules. There's also user experience, understanding the interaction design, visual design, information architecture, and actual content that needs to be presented and which data elements can be manipulated and how, etc. and you need technical architecture skill describe how the design will be implemented. Now it sounds to me like
                      > >
                      > > 1) your developers are well equipped to build and well equipped to handle the technical architecture.
                      > > 2) your PO can define the customer's need (although I'm not certain of this.)
                      > > 3) you may have a gap in design where some or all of the major design tasks are not being handled by anyone. Or no one is willing to own them so they are being handled in an adhoc fashion. This might be an issue of individuals not believing it is their responsibility or a missing skill set within the team.
                      > >
                      > > Let me know if this is on target or not.
                      > >
                      > > -greg
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
                      > > >
                      > > > Greg:
                      > > >
                      > > > He is responsible for all the product of our company, like a VP or a product director.
                      > > >
                      > > >
                      > > > Best regards
                      > > > Chang, Jiang
                      > > >
                      > > >
                      > > >
                      > > > On Dec 4, 2012, at 2:15 PM, "gregc" <greg@> wrote:
                      > > >
                      > > > > Jiang,
                      > > > >
                      > > > > And what are his current responsibilities?
                      > > > >
                      > > > > Thanks,
                      > > > >
                      > > > > -greg
                      > > > >
                      > > > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
                      > > > > >
                      > > > > > Hi Greg:
                      > > > > >
                      > > > > > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
                      > > > > >
                      > > > > >
                      > > > > > Best regards
                      > > > > > Chang, Jiang
                      > > > > >
                      > > > > >
                      > > > > >
                      > > > > > On Dec 1, 2012, at 1:16 PM, gregc <greg@> wrote:
                      > > > > >
                      > > > > > >
                      > > > > > > Jiang,
                      > > > > > >
                      > > > > > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
                      > > > > > >
                      > > > > > > -greg
                      > > > > > >
                      > > > > > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
                      > > > > > > >
                      > > > > > > > Jiang,
                      > > > > > > >
                      > > > > > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
                      > > > > > > > >
                      > > > > > > > >
                      > > > > > > > > Thanks for all your replies.
                      > > > > > > > >
                      > > > > > > > > Charles:
                      > > > > > > > > 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.
                      > > > > > > >
                      > > > > > > > It's all about the conversations. Take a look at
                      > > > > > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
                      > > > > > > > to get some ideas about how these conversations can help.
                      > > > > > > >
                      > > > > > > > - George
                      > > > > > > >
                      > > > > > > > --
                      > > > > > > > ----------------------------------------------------------
                      > > > > > > > * George Dinwiddie * http://blog.gdinwiddie.com
                      > > > > > > > Software Development http://www.idiacomputing.com
                      > > > > > > > Consultant and Coach http://www.agilemaryland.org
                      > > > > > > > ----------------------------------------------------------
                      > > > > > > >
                      > > > > > >
                      > > > > > >
                      > > > > >
                      > > > >
                      > > > >
                      > > >
                      > >
                      > >
                      >







                      --
                      Dipl.-Inform. Markus Gärtner
                      Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development
                      http://www.shino.de/blog
                      http://www.mgaertne.de
                      http://www.it-agile.de
                      Twitter: @mgaertne

                    Your message has been successfully submitted and would be delivered to recipients shortly.