Skip to main content

Business Analyst and Functional Analyst in the Scrum Team

Last post 12:56 am May 26, 2023 by Pierre Pienaar
11 replies
03:22 pm January 3, 2023

Hi

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

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?

Thanks in advance

Daniele 


06:18 pm January 3, 2023

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.


08:36 am January 4, 2023

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 

 


07:12 pm January 4, 2023

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.


09:01 pm January 4, 2023

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.


09:26 am January 5, 2023

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".


12:20 pm January 5, 2023

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.


04:04 pm January 5, 2023

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.  


10:49 am January 16, 2023

Thank you, these were very useful tips!


12:06 pm January 16, 2023

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. 


02:54 am May 24, 2023

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.


12:56 am May 26, 2023

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. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.