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

Business Analyst role

Expand Messages
  • charles_bradley_scrum_coach
    Hi all, I am coaching this new team and I have an interesting situation that I d like to get some opinions on. The team is a fairly typical Scrum team in
    Message 1 of 15 , Sep 18, 2010
    • 0 Attachment
      Hi all,

      I am coaching this new team and I have an interesting situation that I'd like to get some opinions on.

      The team is a fairly typical Scrum team in makeup, and also has a full time Business Analyst(BA) person. The software product is developed by the IT organization, and used by several hundred users who handle customer service calls, requests by mail, etc.

      Some context on the activities of the BA.
      * The BA's background is an assistant supervisory role in the actual customer service department itself.
      * The BA's 'headcount budget' is paid for by the business organization, not IT.
      * The BA coordinates with the PO, but the PO focuses more on the goal level stories, prioritization, and interfacing with the business.
      * The BA spends about 50% of her time researching and documenting business rules, primarily to help flush out acceptance criteria for stories.
      * The business rules are very complicated and involve federal and state financial and tax regulations.
      * Part of this research time is spent researching the regulations themselves, part of it working with other business stakeholders to define how they would like to implement complying with the regulation in the course of their business, and part of it documenting the complex rules and implementation of those rules by the company.
      * This research takes anywhere from 1-12 weeks, and is done anywhere from 1-6 months ahead of the time when the story is developed in a (2 week) sprint.
      * The other ~50% of her time is spent supporting the team directly in the current sprint(clarifications, help in testing, assisting with UAT, etc), but it's hard to pin down most of the discrete support tasks ahead of time, due to the nature of her mostly "supportive" role in the sprint.
      * When this research occurs, the team calls it a "Research Story", assigns story points, and includes those story points in velocity. When the team sizes a story for development, they don't include this research time in their estimate.
      * These "BA research stories" are captured as stories and tasks in the product and sprint backlogs respectively, and only contain tasks for the research (i.e. no dev activities)

      My first impression is that the BA really is sharing the PO role. One of my concerns is that these research stories aren't really backlog items. The time spent researching and drafting the story is really the creation of the Product Backlog Items themselves. Velocity and Story points are supposed to track the relative efforts of turning PBI's into an increment of software. I question whether the BA's time should be tracked on the sprint backlog at all.

      Questions:
      * Should story points be assigned to these research and PBI creation efforts?
      * Should the BA's time/tasks be tracked in the sprint backlog?
      * Do you have any other concerns, given the context/background I gave above?

      Thanks for reading this far and thanks in advance for any help!

      Charles Bradley
      Scrum Coach
      Denver, CO
    • George Dinwiddie
      Charles, ... Yes, I agree with you. It s very natural for BAs to become assistants to the PO where the PO does not already have the knowledge to create the
      Message 2 of 15 , Sep 18, 2010
      • 0 Attachment
        Charles,

        On 9/18/10 7:52 AM, charles_bradley_scrum_coach wrote:
        > My first impression is that the BA really is sharing the PO role.
        > One of my concerns is that these research stories aren't really
        > backlog items. The time spent researching and drafting the story is
        > really the creation of the Product Backlog Items themselves.
        > Velocity and Story points are supposed to track the relative efforts
        > of turning PBI's into an increment of software. I question whether
        > the BA's time should be tracked on the sprint backlog at all.

        Yes, I agree with you.

        It's very natural for BAs to become assistants to the PO where the PO
        does not already have the knowledge to create the proper backlog items.

        No, the research done to create a backlog item should not be tracked in
        the sprint backlog. It's different work, done in a different place in
        the workflow, and done by a different person.

        What I /have/ seen, is a PO team create their own kanban board to track
        the readiness of PBIs as research was done. This was very helpful for
        them in making sure the items were really ready to go before being taken
        into a sprint.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Michael James
        I tend to agree with your thinking about PBIs -- I prefer PBIs to be business-value user stories representing a mixture of development activities (analysis,
        Message 3 of 15 , Sep 18, 2010
        • 0 Attachment
          I tend to agree with your thinking about PBIs -- I prefer PBIs to be business-value user stories representing a mixture of development activities (analysis, design, implementation, integration, testing, etc.), not just the analysis part.  It's better to shake the salad dressing bottle.

          My concern with *not* finding a way to make the research/analysis part of the Sprints is that it may tend to reenforce specialization and working in phases.  Also the BA, a human being, may benefit in unexpected ways from being fully part of a team working toward shared committed goals.

          --mj


          On Sep 18, 2010, at 4:52 AM, charles_bradley_scrum_coach wrote:

          My first impression is that the BA really is sharing the PO role. One of my concerns is that these research stories aren't really backlog items. The time spent researching and drafting the story is really the creation of the Product Backlog Items themselves. Velocity and Story points are supposed to track the relative efforts of turning PBI's into an increment of software. I question whether the BA's time should be tracked on the sprint backlog at all.

          Questions:
          * Should story points be assigned to these research and PBI creation efforts?
          * Should the BA's time/tasks be tracked in the sprint backlog?
          * Do you have any other concerns, given the context/background I gave above?

        • petriheiramo
          Hi, What you re telling sounds to me like a very good thing happening. I wish more teams could have such in-team domain expertise. ... Depends :). But I
          Message 4 of 15 , Sep 19, 2010
          • 0 Attachment
            Hi,


            What you're telling sounds to me like a very good thing happening. I wish more teams could have such in-team domain expertise.

            > * Should story points be assigned to these research and PBI creation efforts?

            Depends :). But I personally might simply measure the velocity based on delivered functionality. The BA is directly contributing to that by helping to define the stories in advance (and then supporting the delivery itself).

            But, I do sometimes include Spikes in story point count, so I don't see it as an issue to count also the research stuff in velocity.

            > * Should the BA's time/tasks be tracked in the sprint backlog?

            Absolutely, even if those activities don't directly applicable to the sprint. You might want to have a separate track for those, though.

            > * Do you have any other concerns, given the context/background I gave above?

            Not really. The only thing might be the length of time spent to refine the requirements and maybe asking if the team could find ways in which to do that faster. But it depends much on stakeholders, so it's not just the team.


            Yours Sincerely, Petri


            --
            - Petri Heiramo -- Agile Coach, CST -- Agilecraft Oy
            - GSM: 040-7092 526 -- Email: petri.heiramo@... -
            - Sudenkatu 10 as 41, 48600 Kotka, Finland -
            - http://agilecraft.wordpress.com/ -
            --
          • Kurt Häusler
            ... I am not disagreeing, but would this not create a situation where Scrum is effectively a local optimization within the implementation phase of a
            Message 5 of 15 , Sep 19, 2010
            • 0 Attachment

              On Sep 18, 2010, at 2:43 PM, George Dinwiddie wrote:
               


              Yes, I agree with you.

              It's very natural for BAs to become assistants to the PO where the PO
              does not already have the knowledge to create the proper backlog items.

              No, the research done to create a backlog item should not be tracked in
              the sprint backlog. It's different work, done in a different place in
              the workflow, and done by a different person.



              I am not disagreeing, but would this not create a situation where Scrum is effectively a local optimization within the "implementation" phase of a traditional organization? I thought a Scrum team was meant to be a cross functional team of everyone required to deliver customer value? By separating the customer facing analysts from the scrum team of developers, and having those BAs work outside of scrum (then presumably throwing their analysis over the wall to be typed in by the programmers) that would be sending the signal that Scrum really is just something that the "geeks" do, and will prevent becoming a true learning organization.

              I say this because I mentioned in another thread that the bulk of the software development occurs outside of scrum, (perhaps it was my mistake considering analysis as part of software development, I notice a lot of Agilists lately are tending to over-glorify the coding part at the expense of the human and business aspects), and it was recognized as a less than optimal situation. We actually had a meeting with our "project management" department, where our BAs live, and they presented their process as a nice waterfall diagram, which was a shock as I thought we were scrum. I asked, and they pointed to the little "implementation" box in the middle and said "thats where you guys do your scrum thing".

              There doesn't seem any point in having scrum if it is only used to "manage" one activity, and it relies on being contained within "the real" product development management process. It would be pure overhead, you may as well just use the true process directly whether it be waterfall or kanban or whatever.

              Scrum is supposed to encompass the whole value stream right? Not just the coding part?

              I would say having BAs outside the scrum teams is a bad habit that is all too easy to justify, as this thread seems to illustrate and something that a true learning organization should try to avoid.

              But I am probably missing something.
            • Andreas
              Hi Kurt, ... Good point. But I did not read that silo thinking out from the original posting. ~50% of her time the BA was collaborating with the (dev) team,
              Message 6 of 15 , Sep 20, 2010
              • 0 Attachment
                Hi Kurt,

                --- In scrumdevelopment@yahoogroups.com, Kurt Häusler <kurt.haeusler@...> wrote:
                >
                > [snip]
                >
                > Scrum is supposed to encompass the whole value stream right? Not just the coding part?
                >
                > I would say having BAs outside the scrum teams is a bad habit that is all too easy to justify, as this thread seems to illustrate and something that a true learning organization should try to avoid.
                >
                > But I am probably missing something.
                >

                Good point. But I did not read that silo thinking out from the original posting. ~50% of her time the BA was collaborating with the (dev) team, that sounds good. Jeff Sutherland once wrote/talked about to get the requirements/user stories "ready" before the whole team works on them in a sprint. During Backlog Grooming Sessions the team prepares estimates and begins to gain an understanding what future stories come. But it's the PO's job (supported by a BA here) to bring in "poker-ready" stories; if it takes several weeks to prepare them, I would say it's ok if the BA works on this preparation in advance, perhaps only loosely coupled with the dev team, where the dev team concentrates on bringing other stories to "done".

                Do you object?

                Cheers,
                Andreas
              • Roman Pichler
                Hi Charles, You are likely to benefit from taking time to reflect on the role the business analyst should play and from investigating who should be the product
                Message 7 of 15 , Sep 20, 2010
                • 0 Attachment
                  Hi Charles,

                  You are likely to benefit from taking time to reflect on the role the business analyst should play and from investigating who should be the product owner. You can find my thoughts on the subject here: http://bit.ly/bSmwYd

                  Best regards,

                  Roman
                  romanpichler.com

                  *** Next public Certified Scrum Product Owner course: 14-15 Oct in London ***

                  --- In scrumdevelopment@yahoogroups.com, "charles_bradley_scrum_coach" <chuck-lists2@...> wrote:
                  >
                  > Hi all,
                  >
                  > I am coaching this new team and I have an interesting situation that I'd like to get some opinions on.
                  >
                  > The team is a fairly typical Scrum team in makeup, and also has a full time Business Analyst(BA) person. The software product is developed by the IT organization, and used by several hundred users who handle customer service calls, requests by mail, etc.
                  >
                  > Some context on the activities of the BA.
                  > * The BA's background is an assistant supervisory role in the actual customer service department itself.
                  > * The BA's 'headcount budget' is paid for by the business organization, not IT.
                  > * The BA coordinates with the PO, but the PO focuses more on the goal level stories, prioritization, and interfacing with the business.
                  > * The BA spends about 50% of her time researching and documenting business rules, primarily to help flush out acceptance criteria for stories.
                  > * The business rules are very complicated and involve federal and state financial and tax regulations.
                  > * Part of this research time is spent researching the regulations themselves, part of it working with other business stakeholders to define how they would like to implement complying with the regulation in the course of their business, and part of it documenting the complex rules and implementation of those rules by the company.
                  > * This research takes anywhere from 1-12 weeks, and is done anywhere from 1-6 months ahead of the time when the story is developed in a (2 week) sprint.
                  > * The other ~50% of her time is spent supporting the team directly in the current sprint(clarifications, help in testing, assisting with UAT, etc), but it's hard to pin down most of the discrete support tasks ahead of time, due to the nature of her mostly "supportive" role in the sprint.
                  > * When this research occurs, the team calls it a "Research Story", assigns story points, and includes those story points in velocity. When the team sizes a story for development, they don't include this research time in their estimate.
                  > * These "BA research stories" are captured as stories and tasks in the product and sprint backlogs respectively, and only contain tasks for the research (i.e. no dev activities)
                  >
                  > My first impression is that the BA really is sharing the PO role. One of my concerns is that these research stories aren't really backlog items. The time spent researching and drafting the story is really the creation of the Product Backlog Items themselves. Velocity and Story points are supposed to track the relative efforts of turning PBI's into an increment of software. I question whether the BA's time should be tracked on the sprint backlog at all.
                  >
                  > Questions:
                  > * Should story points be assigned to these research and PBI creation efforts?
                  > * Should the BA's time/tasks be tracked in the sprint backlog?
                  > * Do you have any other concerns, given the context/background I gave above?
                  >
                  > Thanks for reading this far and thanks in advance for any help!
                  >
                  > Charles Bradley
                  > Scrum Coach
                  > Denver, CO
                  >
                • Kurt Häusler
                  ... I don t object, in general. It depends how the situation came about. If the team, including BAs decided in a retrospective that it was the best way to do
                  Message 8 of 15 , Sep 20, 2010
                  • 0 Attachment
                    On Mon, Sep 20, 2010 at 9:04 AM, Andreas <andreas_thiel@...> wrote:
                     


                    Good point. But I did not read that silo thinking out from the original posting. ~50% of her time the BA was collaborating with the (dev) team, that sounds good. Jeff Sutherland once wrote/talked about to get the requirements/user stories "ready" before the whole team works on them in a sprint. During Backlog Grooming Sessions the team prepares estimates and begins to gain an understanding what future stories come. But it's the PO's job (supported by a BA here) to bring in "poker-ready" stories; if it takes several weeks to prepare them, I would say it's ok if the BA works on this preparation in advance, perhaps only loosely coupled with the dev team, where the dev team concentrates on bringing other stories to "done".

                    Do you object?

                    I don't object, in general. It depends how the situation came about. If the team, including BAs decided in a retrospective that it was the best way to do things then that is fine I guess. If it was decided from the beginning that it should happen that way, then it smells a bit more.

                    To me, taking several weeks to prepare stories, sounds like the kind of impediment to delivering value in an iteration that Scrum is supposed to address. Exactly the kind of impediment that should be highly visible on a scrum board, mentioned repeatedly in standups and retrospectives, and demands organizational change. What if validating stories takes several weeks, lets move that outside the sprint too. What if preparing acceptance tests or deployment takes several weeks?

                    You end up with a team that can only commit to their little part of done, rather than done done.

                    Still if it works, it works I guess. I just think "works" in this case may refer to scrum as a mere estimation and planning tool, rather than its more powerful role as a problem-identifying, team empowering, learning-organization-building tool.
                  • George Dinwiddie
                    Hi, Kurt, ... Well, it might. The Scrum team that I saw do this eventually outstripped the organizations ability to give them work. ... That must be within
                    Message 9 of 15 , Sep 20, 2010
                    • 0 Attachment
                      Hi, Kurt,

                      On 9/19/10 11:55 PM, Kurt Häusler wrote:
                      >
                      >
                      >
                      > On Sep 18, 2010, at 2:43 PM, George Dinwiddie wrote:
                      >>
                      >>
                      >> Yes, I agree with you.
                      >>
                      >> It's very natural for BAs to become assistants to the PO where the PO
                      >> does not already have the knowledge to create the proper backlog items.
                      >>
                      >> No, the research done to create a backlog item should not be tracked in
                      >> the sprint backlog. It's different work, done in a different place in
                      >> the workflow, and done by a different person.
                      >>
                      >
                      >
                      > I am not disagreeing, but would this not create a situation where Scrum
                      > is effectively a local optimization within the "implementation" phase of
                      > a traditional organization?

                      Well, it might. The Scrum team that I saw do this eventually
                      outstripped the organizations ability to give them work.

                      > I thought a Scrum team was meant to be a
                      > cross functional team of everyone required to deliver customer value?

                      That must be within some bound, or you'd pull in every role in the
                      organization.

                      > By
                      > separating the customer facing analysts from the scrum team of
                      > developers, and having those BAs work outside of scrum (then presumably
                      > throwing their analysis over the wall to be typed in by the programmers)
                      > that would be sending the signal that Scrum really is just something
                      > that the "geeks" do, and will prevent becoming a true learning organization.

                      If you operated on that presumption, then you're right. I don't
                      recommend that attitude, though. Nor do I recommend having the top items
                      on the Product Backlog be so vague that the PO-proxies can't answer
                      questions about them.

                      Yes, having a BA as a proxy for a real PO is a bit of an organization
                      smell, but often outside the reach of a young Agile initiative. Over
                      time, perhaps, as the actual business people become accustomed to having
                      software delivered reliably and frequently, they can be tempted to
                      become more involved. I don't recommend waiting for that day before
                      starting Scrum, however. Someone has to go first.

                      > I say this because I mentioned in another thread that the bulk of the
                      > software development occurs outside of scrum, (perhaps it was my mistake
                      > considering analysis as part of software development, I notice a lot of
                      > Agilists lately are tending to over-glorify the coding part at the
                      > expense of the human and business aspects), and it was recognized as a
                      > less than optimal situation. We actually had a meeting with our "project
                      > management" department, where our BAs live, and they presented their
                      > process as a nice waterfall diagram, which was a shock as I thought we
                      > were scrum. I asked, and they pointed to the little "implementation" box
                      > in the middle and said "thats where you guys do your scrum thing".

                      What activities do you consider "analysis?"

                      In the situation I'm describing, it's tracking down people who have the
                      knowledge and authority to answer questions. And the BAs lived and
                      worked in the team room, along with the developers and testers.

                      > There doesn't seem any point in having scrum if it is only used to
                      > "manage" one activity, and it relies on being contained within "the
                      > real" product development management process. It would be pure overhead,
                      > you may as well just use the true process directly whether it be
                      > waterfall or kanban or whatever.
                      >
                      > Scrum is supposed to encompass the whole value stream right? Not just
                      > the coding part?
                      >
                      > I would say having BAs outside the scrum teams is a bad habit that is
                      > all too easy to justify, as this thread seems to illustrate and
                      > something that a true learning organization should try to avoid.
                      >
                      > But I am probably missing something.

                      Yes, I think you are. Sure, it /can/ be as dysfunctional as you
                      describe. But it's not necessarily so. When you get to an organization
                      with thousands of people, they can't all be on one scrum team. At some
                      point the scrum team has to interface with the rest of the organization.

                      But I don't think anyone suggested having BAs outside the scrum team.
                      Instead, I suggested having the PBI creation outside of the scrum
                      sprint. I don't think I've ever seen any scrum books recommending
                      putting the PBI creation inside the sprint.

                      - George

                      --
                      ----------------------------------------------------------------------
                      * George Dinwiddie * http://blog.gdinwiddie.com
                      Software Development http://www.idiacomputing.com
                      Consultant and Coach http://www.agilemaryland.org
                      ----------------------------------------------------------------------
                    • Don MacIntyre
                      It sounds like your Analyst is making herself very useful and providing a great deal of value to the PO and the team. If the team has found a way to
                      Message 10 of 15 , Sep 20, 2010
                      • 0 Attachment
                        It sounds like your Analyst is making herself very useful and providing a great deal of value to the PO and the team. If the team has found a way to incorporate her work into the sprint, is assigning story points, etc., and all is well – why change?

                        I've worked with a couple of teams with Analysts in very similar roles and we did not track tasks – and that worked as well. We considered it PO support.

                        It does occur to me that if your Analyst is spending 50% of her time helping the PO define business rules for stories months ahead of the sprint, it sounds like there would be potential that the scrum team might not even be formed when the Analyst starts working on investigating some of those stories.

                        -don

                        --- In scrumdevelopment@yahoogroups.com, "charles_bradley_scrum_coach" <chuck-lists2@...> wrote:
                        >
                        > Hi all,
                        >
                        > I am coaching this new team and I have an interesting situation that I'd like to get some opinions on.
                        >
                        > The team is a fairly typical Scrum team in makeup, and also has a full time Business Analyst(BA) person. The software product is developed by the IT organization, and used by several hundred users who handle customer service calls, requests by mail, etc.
                        >
                        > Some context on the activities of the BA.
                        > * The BA's background is an assistant supervisory role in the actual customer service department itself.
                        > * The BA's 'headcount budget' is paid for by the business organization, not IT.
                        > * The BA coordinates with the PO, but the PO focuses more on the goal level stories, prioritization, and interfacing with the business.
                        > * The BA spends about 50% of her time researching and documenting business rules, primarily to help flush out acceptance criteria for stories.
                        > * The business rules are very complicated and involve federal and state financial and tax regulations.
                        > * Part of this research time is spent researching the regulations themselves, part of it working with other business stakeholders to define how they would like to implement complying with the regulation in the course of their business, and part of it documenting the complex rules and implementation of those rules by the company.
                        > * This research takes anywhere from 1-12 weeks, and is done anywhere from 1-6 months ahead of the time when the story is developed in a (2 week) sprint.
                        > * The other ~50% of her time is spent supporting the team directly in the current sprint(clarifications, help in testing, assisting with UAT, etc), but it's hard to pin down most of the discrete support tasks ahead of time, due to the nature of her mostly "supportive" role in the sprint.
                        > * When this research occurs, the team calls it a "Research Story", assigns story points, and includes those story points in velocity. When the team sizes a story for development, they don't include this research time in their estimate.
                        > * These "BA research stories" are captured as stories and tasks in the product and sprint backlogs respectively, and only contain tasks for the research (i.e. no dev activities)
                        >
                        > My first impression is that the BA really is sharing the PO role. One of my concerns is that these research stories aren't really backlog items. The time spent researching and drafting the story is really the creation of the Product Backlog Items themselves. Velocity and Story points are supposed to track the relative efforts of turning PBI's into an increment of software. I question whether the BA's time should be tracked on the sprint backlog at all.
                        >
                        > Questions:
                        > * Should story points be assigned to these research and PBI creation efforts?
                        > * Should the BA's time/tasks be tracked in the sprint backlog?
                        > * Do you have any other concerns, given the context/background I gave above?
                        >
                        > Thanks for reading this far and thanks in advance for any help!
                        >
                        > Charles Bradley
                        > Scrum Coach
                        > Denver, CO
                        >
                      • charles_bradley_scrum_coach
                        Thanks to all for your feedback. Kurt, a clarification. The BA s do not and would not be outside of the Scrum team in this scenario. They are collocated
                        Message 11 of 15 , Sep 20, 2010
                        • 0 Attachment
                          Thanks to all for your feedback.

                          Kurt, a clarification. The BA's do not and would not be "outside" of the Scrum team in this scenario. They are collocated with the team. Like I said, about 50% of their time is spent creating PBI's and the other 50% is supporting the team in a collaborative way as Scrum suggests. There is NOT a throw it over the wall mentality, but I agree with you that would be horrible. I also think the waterfall scenario you mentioned reflects a misunderstanding on behalf of your PMO and BA. The "50%" dev team support function is what separates BA waterfall from BA Scrum, IMO.

                          Your point about noting that scrum is more than just coding and testing is duly noted. OTOH, it is very clear in the Scrum Guide that the PO has the responsibility (which means she can be supported by others) of making sure the PBI's for the next several sprints are fine grained and clear. To, me, this suggests that a) the PO and those that support her do some of their work "ahead" of the dev team and b) that those activities, which may or may not be tracked as part of the sprint backlog, are STILL part of Scrum.

                          Charles


                          --- In scrumdevelopment@yahoogroups.com, Kurt Häusler <kurt.haeusler@...> wrote:
                          >
                          >
                          > On Sep 18, 2010, at 2:43 PM, George Dinwiddie wrote:
                          > >
                          > > Yes, I agree with you.
                          > >
                          > > It's very natural for BAs to become assistants to the PO where the PO
                          > > does not already have the knowledge to create the proper backlog items.
                          > >
                          > > No, the research done to create a backlog item should not be tracked in
                          > > the sprint backlog. It's different work, done in a different place in
                          > > the workflow, and done by a different person.
                          > >
                          > >
                          > >
                          >
                          > I am not disagreeing, but would this not create a situation where Scrum is effectively a local optimization within the "implementation" phase of a traditional organization? I thought a Scrum team was meant to be a cross functional team of everyone required to deliver customer value? By separating the customer facing analysts from the scrum team of developers, and having those BAs work outside of scrum (then presumably throwing their analysis over the wall to be typed in by the programmers) that would be sending the signal that Scrum really is just something that the "geeks" do, and will prevent becoming a true learning organization.
                          >
                          > I say this because I mentioned in another thread that the bulk of the software development occurs outside of scrum, (perhaps it was my mistake considering analysis as part of software development, I notice a lot of Agilists lately are tending to over-glorify the coding part at the expense of the human and business aspects), and it was recognized as a less than optimal situation. We actually had a meeting with our "project management" department, where our BAs live, and they presented their process as a nice waterfall diagram, which was a shock as I thought we were scrum. I asked, and they pointed to the little "implementation" box in the middle and said "thats where you guys do your scrum thing".
                          >
                          > There doesn't seem any point in having scrum if it is only used to "manage" one activity, and it relies on being contained within "the real" product development management process. It would be pure overhead, you may as well just use the true process directly whether it be waterfall or kanban or whatever.
                          >
                          > Scrum is supposed to encompass the whole value stream right? Not just the coding part?
                          >
                          > I would say having BAs outside the scrum teams is a bad habit that is all too easy to justify, as this thread seems to illustrate and something that a true learning organization should try to avoid.
                          >
                          > But I am probably missing something.
                          >
                        • charles_bradley_scrum_coach
                          See below. ... * The one reason I can think for changing is that story points(and PBI estimates) are meant to measure the relative amount of work to turn a PBI
                          Message 12 of 15 , Sep 20, 2010
                          • 0 Attachment
                            See below.

                            --- In scrumdevelopment@yahoogroups.com, "Don MacIntyre" <don@...> wrote:
                            >
                            > It sounds like your Analyst is making herself very useful and providing a great deal of value to the PO and the team. If the team has found a way to incorporate her work into the sprint, is assigning story points, etc., and all is well – why change?
                            >

                            * The one reason I can think for changing is that story points(and PBI estimates) are meant to measure the relative amount of work to turn a PBI into a done increment of software. Used for planning purposes, story points help the Scrum team plan releases and sprints, and help the customer decide which features have the highest business value when taking into account the relative cost of each. I think assigning story points should either:
                            a) always include the PBI creation time into the whole estimate for the PBI, thus allowing the dev team and business to measure the business value ROI against the relative cost, OR
                            b) never include the PBI creation time(much like the PO's time to create PBI's is generally not included in a PBI estimate), and instead should reflect the development team's ability to turn PBI's into story points. The business value ROI story point cost can still be taken into account at this point.

                            Option b) is simpler, but option a) almost seems more accurate, especially in this situation with complicated business rules. The risk of option a) is that it's complicated because then you have to split the epic into several supporting stories, some that involve detailing other stories(requirement research stories), and some that involve the transformation of the detailed stories into a software increment.

                            Does anyone have any other advice about these two paths? It's much appreciated.

                            >
                            > -don
                          • charles_bradley_scrum_coach
                            Roman, Excellent link, sir, and the links from your article are also excellent. I m a big fan of your work(esp your book) and will be recommending your book
                            Message 13 of 15 , Sep 20, 2010
                            • 0 Attachment
                              Roman,

                              Excellent link, sir, and the links from your article are also excellent. I'm a big fan of your work(esp your book) and will be recommending your book to this team.

                              So far, it seems like Cohn's _Succeeding With Agile_ and your book and articles are the best sources I can find on how to incorporate BA's into the Scrum Team. Dean Leffingwell also has some some material in his articles on the role.

                              Charles


                              --- In scrumdevelopment@yahoogroups.com, "Roman Pichler" <roman.pichler@...> wrote:
                              >
                              > Hi Charles,
                              >
                              > You are likely to benefit from taking time to reflect on the role the business analyst should play and from investigating who should be the product owner. You can find my thoughts on the subject here: http://bit.ly/bSmwYd
                              >
                              > Best regards,
                              >
                              > Roman
                              > romanpichler.com
                              >
                            • David A Barrett
                              To me, the issue boils down to one question, Is the Team (or should the Team be) responsible for the creation of the specifications that the BA is
                              Message 14 of 15 , Sep 20, 2010
                              • 0 Attachment
                                To me, the issue boils down to one question, "Is the Team (or should the Team be) responsible for the creation of the specifications that the BA is producing?".   Because if it is (or should be), then it's clearly something that should be part of the Sprint.

                                What's probably more complicated is whether all this pre-coding specification stuff really needs to be done separately.  Ideally, you should go into a Sprint having done the bare minimum of work to be able to estimate well enough to plan a Sprint.  What's the chances that the specifications can be brought together as the development, just like in any other Scrum project?

                                I noticed that this:

                                >* The BA spends about 50% of her time researching and
                                >  documenting business rules, primarily to help flush out
                                >  acceptance criteria for stories.
                                >* The business rules are very complicated and involve
                                >  federal and state financial and tax regulations.
                                >* Part of this research time is spent researching
                                >  the regulations themselves, part of it working with
                                >  other business stakeholders to define how they
                                >  would like to implement complying with the regulation
                                >  in the course of their business, and part of it
                                > documenting the complex rules and implementation
                                >  of those rules by the company.

                                Doesn't really sound any different from what I'd expect you'd find in any company, in any Scrum team, anywhere.

                                But this:

                                >* This research takes anywhere from 1-12 weeks,
                                >  and is done anywhere from 1-6 months ahead of
                                >  the time when the story is developed in a
                                >  (2 week) sprint.

                                Looks like a smell to me.  3 months of specifications, half a year ahead of time, for 2 weeks of programming??????????

                                I'd be questioning that.  Hard.  Find out how much of this stuff actually gets used.  Do the programmers look at it?  All of it?

                                In my experience, this kind of heavyweight, up-front requirements analysis, especially when done by someone who came into the BA role through the business operations side (instead of the IT side) is usually misguided, and often completely incomprehensible to the developers.  So I'd start by asking the programmers, "What do you need", and then move forward from that.


                                Dave Barrett


                                This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

                                Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
                              • charles_bradley_scrum_coach
                                See *** s below. ... I agree 100% with you, and I kind of slipped that in to see if anyone else would have the same concern as me. Essentially, I was looking
                                Message 15 of 15 , Sep 22, 2010
                                • 0 Attachment
                                  See ***'s below.

                                  --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
                                  >
                                  > To me, the issue boils down to one question, "Is the Team (or should the
                                  > Team be) responsible for the creation of the specifications that the BA is
                                  > producing?". Because if it is (or should be), then it's clearly
                                  > something that should be part of the Sprint.

                                  *** I'm not really concerned with whether they are part of the sprint are not, because they definitely are. What I'm concerned with is whether they should be called "user stories", assigned story points, and should be counted as part of velocity, or whether they should be assigned estimates as hours/tasks, which would not include them as part of velocity. What I haven't revealed yet, and only because I already know the answers, is that this team also assigns story points to defects, the effort of "release planning", regression testing, UAT testing, deployment activities, technical infrastructure(often because they do horizontal slicing instead of vertical), and other technical efforts (like installing/using a performance tool) that are not directly related to providing "running, tested, features" that are primarily of value to end users. So, I have a strong concern about what should be assigned story points and what shouldn't. My assessment so far is that their velocity number measures something quite different than what velocity was meant to measure. This BA research effort is the only activity that I can justify assigning story points and also justify not assigning story points. Most of the rest of those efforts should be included as story points in the actual end user story estimates themselves, if they are truly directly related to delivering running, tested, end user features.


                                  >
                                  > What's probably more complicated is whether all this pre-coding
                                  > specification stuff really needs to be done separately. Ideally, you
                                  > should go into a Sprint having done the bare minimum of work to be able to
                                  > estimate well enough to plan a Sprint. What's the chances that the
                                  > specifications can be brought together as the development, just like in
                                  > any other Scrum project?

                                  *** Pretty slim I think. Much of the research time really does require 1-3 (2 week) sprints to both research and negotiate with the business stakeholders how the business logic will be implemented. The rest of the work (say more than 3 sprints out), IMO, is really a BRUF or BAUF (Big Analysis Up Front) effort as you suggest below.


                                  >
                                  > But this:
                                  >
                                  > >* This research takes anywhere from 1-12 weeks,
                                  > > and is done anywhere from 1-6 months ahead of
                                  > > the time when the story is developed in a
                                  > > (2 week) sprint.
                                  >
                                  > Looks like a smell to me. 3 months of specifications, half a year ahead
                                  > of time, for 2 weeks of programming??????????
                                  >
                                  > I'd be questioning that. Hard. Find out how much of this stuff actually
                                  > gets used. Do the programmers look at it? All of it?
                                  >
                                  > In my experience, this kind of heavyweight, up-front requirements
                                  > analysis, especially when done by someone who came into the BA role
                                  > through the business operations side (instead of the IT side) is usually
                                  > misguided, and often completely incomprehensible to the developers. So
                                  > I'd start by asking the programmers, "What do you need", and then move
                                  > forward from that.
                                  >

                                  I agree 100% with you, and I kind of slipped that in to see if anyone else would have the same concern as me. Essentially, I was looking for validation and didn't want to express my concern in a way that skewed the feedback I got from the list. (so I wasn't trying to "test" the list or anything like that)

                                  I especially like your last sentence about asking the developers "What do you need?". I think what might also be equally as important, though, is asking the customers(aka business stakeholders) "What do you need?" in terms of understanding how a business requirement will be implemented as business logic that supports a feature in the software. The business needs to validate that we have understood the business logic correctly so that the dev team programs that logic correctly into the software increment. (Just like any other detailed functional requirements effort)

                                  So, in summary, we have two different audiences to communicate with, and I think I should advise them to make sure they are doing the minimum amount of analysis/documentation that could possibly work to satisfy both audiences.

                                  Thanks so much for everyone's feedback.
                                Your message has been successfully submitted and would be delivered to recipients shortly.