4

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?

Improve this question
3

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.

Improve this answer
3
  • 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
3

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.

Improve this answer
1
  • 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
1

Stories are a tiny piece of functionality, a piece of code that is testable and provides some value. As such the workflow should be that they are raised, analysed, coded, tested, released.

As such these are owned by the team as a whole and as part of the work pipeline will transition from one 'discipline' / expert to another. If you must, you can use sub-tasks which 'hang off' stories, which would then be 'analysis', 'coding' etc. Or you could (which I do) have columns in your backlog which are 'Analysis', 'Coding', 'Testing', 'Done'...

I have been in exactly the situation you describe which usually happens when we try to have too much detail in regards to tasks around our stories (which tools such as JIRA and VSTS are not made to handle well - even if they say they do). You need to ask yourself the question: Do you really need all that detail or is it not much clearer and easier to simply have a story nicely float through its lifecyle.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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