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

Re: Business Analyst role

Expand Messages
  • 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 1 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.