Is it common for business analysts (or other non-development team members) to have stories tracked alongside developers?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.