Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We're using JIRA with Greenhopper, and currently our business analyst has tasks for their analysis which will eventually lead to new stories placed in the backlog, running alongside the stories for the current sprint, and it feels kind of messy - especially because they don't overlap the workflow for the development stories.

Is it common for this to be the case? Should it be? It feels like the analysis ought to be an external process that feeds in to the product backlog, not something that tags along the sprint backlog, but I am new to scrum.

I consulted the scrum guide and didn't see anything explicit, and while we don't really have a Product Owner (although at times I would say our manager fills that role, other times so does the business analyst), I guess I could also phrase the question as:

Should Product Owners track their tasks next to the stories that the development team works on?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

Are the Business Analysts part of the Team? If so, then consider that the Scrum Guide is pretty clear on not dividing the team into roles:

  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,
  • Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

As such, either the BAs are equal members of the team, and thus their work is too, or they are not and it is not. If they are part of the team, and there is a task with a measurable goal (you know when it's "done"), then it is a viable task in the Sprint Backlog.

Moreover, a User Story is a story about functionality the user is asking for. It is not a list of work to be done, as such. So again, what you are talking about isn't really a "story".

So, on the practical side, I'd suggest that you include folks with business analyst skills on your team and use them to help complete your stories. The team won't know everything about a story before they start on a story--they just know there's something they need to learn about and solve. The ones with business analyst skills are going to be really helpful in elaborating the stories and translating business speak to something that can be coded and tested. If, during sprint planning, you determine there are analysis tasks to be done, add them to your sprint backlog and have someone work on them.

share|improve this answer
    
We're an internal tools team, and so our "customer" is in fact sometimes ourselves, where one tool needs another tool to change its behaviour or start performing functionality so that another tool can satisfy a requirement. Are you saying we should capture those items some other way? If we actually assemble the desired functionality in to one statement, it's never much more than "I want to click Generate Report and receive a report of all the Widgets". Except that requires integration with 6 different systems and a whole tonne of stuff that the customer outright refuses to acknowledge exists. –  Doug Aug 4 '12 at 2:47
    
What I mean by that last part, is we have say, 6 systems, and many teams work only with 1 system and if they come to you talking about requirements, and you say, "oh but this other system has this, so.." it's basically "well, we don't use that system, and that system is stupid, and no one should have ever used it." - so in order to have our sprints focus on items that are of a managable size (some of these things would be a month of work), I guess we opted to perverse the meaning of story to that of "internal dialogue" –  Doug Aug 4 '12 at 2:49
    
So, basically, they have a story saying they need a report with X information, where X is really A, B. C, D, E, and F, all coming from different systems? I think it's valid for you to break consider the larger report an epic with several stories (e.g., "I need the A information so I can garflup", etc.) The analyst folks would still be part of the team helping get that bit of it done. –  Matthew Flynn Aug 4 '12 at 3:46

In my experience ...

Pros:

  • It gives developers a warm feeling that they're not the only ones expected to be transparent.
  • It does help the Product Owner understand the process.

Cons:

  • It gives Product Owners the belief that what they do is comparable somehow to what developers do.
  • It complicates the work board unnecessarily.
  • It offers very little genuinely useful information to anyone.

Personally, I think the pros can be achieved in other ways. But the cons are not unacceptable, so if the Product Owner REALLY wants it, let them have it until it proves a waste of time.

share|improve this answer
    
That's what I thought. Presumably, the Product Owner is accountable to someone else (especially in a large organization like this), and so that transparency is really pertinent elsewhere anyway: the product owners boss isn't using this tool to check up on him (most likely), and the development team can't really do anything with said transparency. Thanks for your input! –  Doug Aug 3 '12 at 17:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.