Business Analyst and Functional Analyst in the Scrum Team

I have to train a Scrum Team where there are in addition to Developers, Business Analysts and Functional Analysts.

Are you satisfied that those analysts are not in fact Developers: i.e. that their industry is not needed to plan and build a Done increment each Sprint?

I am not sure how to handle this. Should the "Definition of Ready" already include the functional analysis? Or should I see the functional analysis as a task?

Perhaps both. Perhaps enough of each are needed to satisfactorily refine the work, and to ensure that it can be Done in a Sprint before actually doing it.

Hello Ian,

personally, I did not like having analysts on the Scrum Team, but this was imposed by the company. 

At the moment, the Team has several status for the User Strories: New, Analysis in Progress, Analysis Done, Dev in Progress, .... up to 'DONE'.

What I wonder at this point is whether I should consider the Sprint Planning committment based only on the User Stories that are in the 'Analysis Done' status.

In this case, the Story Point estimation would be related only to the 'Development', decoupling both business and functional analysis from the estimation.

The downside would be that the user stories to be analysed would still have to be taken into account in Sprint Planning, as a matter of follow-up.

Do you think this is a correct approach?

Kr,

Daniele 

These sound like poor Sprint Planning commitments to me. Better commitments might be:

• to meet a Sprint Goal which mitigates a significant risk or challenge, and which actually gives the Developers a reason to work together this Sprint
• to produce at least one Done finished increment this Sprint, of immediately usable quality, and which would allow the team to empirically validate their assumptions.

These are the Sprint Planning commitments Scrum describes, and it is the Developers who ought to make them. They are the ones doing the work.

The workflow Developers follow should support their ability to make these commitments. Work should be refined and made ready for Sprint Planning, at which point Sprint commitments can be made. The workflow should also be visible, and ought to provide transparency over organizational impediments -- such as policies being imposed by others -- so they can then be constructively challenged.

What I wonder at this point is whether I should consider the Sprint Planning committment based only on the User Stories that are in the 'Analysis Done' status.

Why should you be making this decision?  The Developers are the ones responsible for creating the Sprint Backlog out of a subset of items in the Product Backlog.  They are the ones that do the work and will estimate the effort.  

While the Scrum Guide does not provide any guidance on job titles that are considered to be included in the Developers responsibility, it does give guidance to the extent of the Developers work. 

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

I have worked with teams that decided analysts were considered Developers by the Scrum Team.  I have also worked with teams that decided the Analysts were considered to be contributing the Product Owner responsibility instead of the Developer.  But the common part in both of those situations is that "the team decided" not an individual.

In your original question, you asked about the "Definition of Ready".  That is not something that the Scrum framework includes.  So, to answer that question, you should be asking the team how they would like to handle it.  Remember that there is no specific way that things have to be done in the Scrum framework.  The Scrum Team is self-organizing and self-managing.  So let them discuss and decide how they should do it.  As an Agile Coach, you are more responsible for helping people become students of Empiricism and to be team centric in their decision making rather than having someone tell them how to do things.  What is right for one team may not be right for another. So coach them to make their own decisions and you could use this topic as a great way to help them learn how to be self-managing.

Hi

Thanks for the answers, very interesting.

This is true, this is actually the team that has to be able to choose, but their maturity level is very low.

I think I will put these 2 options in front of them and they may be able to choose:

1) business analyst work is considered as refinement until they have clear ideas, so it does not enter in the 'Sprint planning' process in the strict sense.

2) the team sees the business analyst's work as a 'task' of the user story, and thus falls within the 'Sprint planning'.

The objection to the second option is always the following: "We cannot estimate something we do not know, because the analysis is not yet clear".

Presenting the team with your 2 options is not the same as bringing it to the team for them to work through and decide for themselves.

The Scrum Guide provides some simple, yet powerful guidance...

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

The Team will know best which PBIs are deemed ready for selection, and this may even differ PBI to PBI. Depending on the PBI, ready for selection could include the Team doing analysis during the Sprint. 

Regarding "We cannot estimate something we do not know, because the analysis is not yet clear". Complex work is full of unknowns, and sizing can accommodate for it. If the Team determines that those unknowns mean the the PBI will likely take longer than one Sprint, it is a good indicator that it isn't ready for selection and requires more refinement until it is clear enough to be deemed ready.

This is true, this is actually the team that has to be able to choose, but their maturity level is very low.

That is not excuse for doing their work for them. How else will they gain maturity?  It is much like a child.  They have to make mistakes in order to learn.  So far, you have not shown that the team thinks there is an issue so how will they understand why something else needs to be done.  Or for that matter, does something else need to be done?  

Think a minute about coaches.  Where are coaches most common?  Sports.  What do coaches of sport teams do?  They provide the team guidance.  They teach them skills that can be used while in the moment. They provide plans that can be used but it is up to the players to adapt based upon the current situation using the skills they have learned.  The people on the team need to be able to adapt as they need and when they need, not when told by a coach to do so.  

Everything in Scrum is based upon empiricism.  Empiricism says that all knowledge is gained from sense-experience.  

Thank you, these were very useful tips!

I have a similar team setup with a Business Analyst. I struggled also some time with the role in the Scrum setup. As already mentioned, the key is to get rid of the waterfall within the team. This can be done with and without the BA. 

Also for me, a BA might be a sign of an dynsfunctional organization setup where a team has too big area of responsibility where the PO is overloaded and got an BA as supporter. 

From my opinion, as a practitioner in project management for over 20 years, when it comes to talking about the Scrum team, it always raises the concern about the role of business analyst.

(a) Should the business analyst be part of the development team?

(b) Should the business analyst be under the supervision of PO or the proxy of PO?

Business analysts end up as proxy product owners, a go-between the real decision maker and the development team.

PO => BA => Development team



Read more at: https://www.romanpichler.com/blog/business-analysts-in-scrum/

 

(c) Should the business analyst be another team regarded as business stakeholders?

Similar to (b), business analysts end up as proxy business stakeholders, a go-between the real decision maker and the development team.

Business Units => BA => PO => Development team

Let's go back to the day before Agile/Scrum was born. We have the phase of requirement gathering. If we consider the business requirement analysis as an important task that contributes to the success of the product, why not include the task as a backlog item and include the business analyst be part of the development team. In fact, if the development team becomes more mature, it will be more efficient to have the business analysis performed by developers. It is much easier for a technical to develop his/her business analysis skills and communication skills but not the opposite way.

Not to say what is wrong or right, but I  have also seen this configuration for teams. Each team has a member that is business analyst focused. Only stories that has been analysed and estimated gets pulled in to the sprint backlog during planning. (Items get pushed back that lack enough analysis detail.) Only development items and spikes make it to the sprint backlog. The analysis work, unless a spike, don't get to the sprint backlog.  

Possible not Ideal, the teams do not get to decide their makeup. Then I don't see a real impediment either. There are advantages to have a BA focused member on a team, to provide functional knowledge and help in testing. 

The one challenge I find though is to guard that the analysts don't operate as an extension to the PO, and either direct all decisions or be an extension for the PO to "pull strings" during team decisions. 

I capture this thread for similar thoughts. In my company, we have complete, cross-functional "product teams". When comparing it to a Lean UX approach, I would say that our discovery and development phase are quite entwined. Meaning that we do a lot of planning and prototyping upfront, before the concept goes into production. 
In our team are BAs, UX, Architect, PO and the SW-Devs, so to speak: A business and a dev team. For me, it's hard to get a grip on that structure. We do want to stress the unity of the product team, and that we do need every skill to provide end2end development of our tool(s) of the companies' application. 
But we do have a felt seperation between biz and devs, but also a feeling of overall unity. Meaning, that everybody is participating in all Scrum Meetings. Which is quite nice, because Business und SW-Devs communicate regularly and we're having a common understanding of what we're doing.
I tried to interpret everybody but the PO as a Developer, when referring to the Scrum Guide: when a Scrum Team member isn't a PO or a SM, it has to be a Developer IMHO, even if she's doing PO-work. But that somehow isn't relating to our actual workflow, that our discovery phase with prototyping is done upfront (which has biz-related reasons that I have little influence on). When it comes to self-management, I would say that our structure doesn't foster it, especially when it comes to the SW-Devs. As I said, slippery grip. 

I have concluded three scenarios: 

1. try to work the company to loosen regulations, that our teams are able to integrate discovery & development in one agile Lean UXish Scrum Process, which our structure is prepared for.
2. interpreting our business team as stakeholders and exclude them from some Scrum Meetings to have the focus on self-management and the SW-Developers that are actual doing the production work. 
3. never stop a running system. Structure feels a bit odd to me and we kinda tweaked Scrum mechanics to fit our structure, but we do deliver regularly, have a high standards and our app-user count is raising.