BSA's role in a scrum team; Extension of Product Owner?

I couldn't edit the above but I thought I'd clarify that the BSAs in our team do analysis work only. They do not do any actual development or testing.

While "T-shaped" developers (those with skills across multiple areas that you describe) can be a benefit to Scrum teams, there is no requirement for every team member to be cross functional; there simply must enough cross functional skills within the team for them to successfully build increments to a potentially releasable state.

As you've identified, a team size of 11 is just over the recommended size of a Scrum team. However, if it's working for you and your team, I wouldn't get too hung up on the Scrum Guide recommending 3-9. This is to mitigate dysfunctions that may occur in smaller/larger team sizes and wrangling your figures to fall within this range won't actually solve those problems. Come back to it if the team does start to struggle - perhaps you could make two smaller Scrum teams from those members, for example?

If a Development Team were to say, truthfully, "we need pizza in order to do our work", then the pizza delivery guy may reasonably be considered a Development Team member.

In your situation, is the work of a BSA only necessary for refinement, or is it needed in order to create a Done increment and to meet the Sprint Goal?

@Ian Mitchell,

In my case, the BSA is needed for both refinement and for the initial requirements and mapping/design work. The BSA does not do any development or testing.

Because, the BSA does not do any development or testing work their motivation to be on the daily standup is also less. They are only focussed on that specific aspect of the work, which also results in them not being utilized to full capacity.

I therefore felt if they were an extension of the PO, then it would be a better team structure. i.e. be responsible for maintaining the backlog etc.

Correct my thought, however, I feel that as scrum is a framework, there isn't really an exact measure of what is right or wrong. It can be tweaked as long as it adds value without being too specific. But are there any hard boundaries or rules that shouldn't be crossed? Why do some known experts on Agile suggest not having the whole team during a refinement session and some suggest it should be the whole team?

For example, daily standup should be 15 mins or is recommended to be 15 minutes? cross functional team vs cross functional team members?

I think my dilemma is with respect to some aspects of what is prescribed in the scrum guide vs what is practiced and understood. for ex: in a recent post I read about a true/false question that came in the PSK Open. Here is an excerpt from that:

"True or False: When using Scrum with Kanban you can have multiple items in a "releasable" state during the Sprint" 

vs. the Scrum guide

"the work of delivering a potentially releasable Increment of "Done" product by the end of each Sprint"

Whilst I agree with both aspects isn't there an argument for each, we can release during sprint as long as the PO and stakeholders sign-off, but should we do it that way or should we wait till the Sprint Review to do the same?

Correct my thought, however, I feel that as scrum is a framework, there isn't really an exact measure of what is right or wrong. It can be tweaked as long as it adds value without being too specific. But are there any hard boundaries or rules that shouldn't be crossed?

Yes, there are hard boundaries and rules that shouldn't be crossed. The Scrum Guide says: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices."

Why do some known experts on Agile suggest not having the whole team during a refinement session and some suggest it should be the whole team?

The guide is clear that the Product Owner and Development Team are involved:

"Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items."

If any participant is not present, then the collaboration referred to would be compromised to at least some degree, and the ability to refine work to a "ready" state would be put at risk. That risk may or may not be acceptable depending upon the situation and context. If one team member is missing, then it might be possible to conduct a refinement session to a sufficient standard, or it might not.

"True or False: When using Scrum with Kanban you can have multiple items in a "releasable" state during the Sprint" 

vs. the Scrum guide

"the work of delivering a potentially releasable Increment of "Done" product by the end of each Sprint"

Whilst I agree with both aspects isn't there an argument for each, we can release during sprint as long as the PO and stakeholders sign-off, but should we do it that way or should we wait till the Sprint Review to do the same?

As long as the Development Team are satisfied that work meets the Definition of Done, then no sign-off or approval for release may be necessary. The Product Owner may expect a continuous flow of Done work into production, and authorization for release may then be implicit. However, since a Product Owner is accountable for value, he or she may alternatively reserve the right to explicitly authorize each release, a decision which might be influenced by the latest business conditions. The Scrum Framework makes no prescription either way about this matter.

the BSA does not do any development or testing work

Considering the detailed knowledge gathered by this person, seems like a fine candidate to author test scenarios and review test cases. As well as verifying updates to the Sprint backlog.

@Paul and the community, 

Considering the detailed knowledge gathered by this person, seems like a fine candidate to author test scenarios and review test cases. As well as verifying updates to the Sprint backlog

Doesn't the PO do a very similar job? How is the work of the PO different from the BSA? In my opinion, they both are close to the business, are able to understand what work is of value to the customer/stakeholder, what needs to be prioritized etc? If there was no BSA, then wouldn't the PO bring the high level work, refine with the developers, if pending questions exist go back to the stakeholder etc? Finally, isn't the PO the one who Accepts or Rejects the Increment at the end of the sprint?

The PO is responsible for the Product Backlog per the Scrum Guide.  But read this statement, found in the section that describes the PO, carefully. 

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

It shows that the PO can delegate some of this work but it is specific in to whom. While in my opinion, your version of the BSA would not be part of the Development Team, there is nothing in the Scrum Guide or any interpretation of it that says it can't happen.  But this statement that follows the previous sentence might help with this.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

In the case you describe, I would see the "committee" being the PO and the BSA.  But in the end, the PO is the one that represents that committee to the Scrum Team.

Finally, isn't the PO the one who Accepts or Rejects the Increment at the end of the sprint?

Where in the Scrum guide do you find that statement?  There is only place that states this in any way and it is when talking about a canceled sprint.  But there is no other place.  I have always felt that the "accept or reject" has no place in Scrum.  The Definition of Done is your contract on when something is "done".  In the section describing the Product Backlog in the Scrum Guide, you will find this statement.

Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

If you satisfy the Definition of Done to which all parties have agreed and the "test descriptions that will prove its completeness" why do you still need someone to accept or reject.  Everyone in the Scrum Team has been involved in the definition and understanding of those items.  By satisfying them, the work is accepted.  If you don't satisfy them, the work is rejected. 

The rejection of work implies that waste has been incurred. This ought to be minimized by introducing quality checks, at each point where value is added, so that work will meet the Definition of Done. In Scrum, the concept of acceptance or rejection is therefore not particularly useful. A team inspects and adapts instead.

@Dan, 

Thanks for your comments and how you've used the scrum guide to share your views. From what you've explained, I can only conclude that a BSA can fit in either places, either as a member of the development team, where they would help maintain the backlog, write user stories etc. based on the work that the PO delegates, OR they could be working along side the PO and the PO will eventually release the work to the development team based on value.

The reason I initiated this discussion was because in my team, even though we have a PO, the role has a dual function, i.e. PO/BSA. There are also BSA's in the team. The problem I am facing is that they are not taking the ownership of maintaining or updating relevant information in the backlog. for ex: updating, adding, deleting or creating user stories, keeping release dates updated etc. They expect that the scrum master should be the one doing all this.

I believe that these things should be done by the PO or the development team i.e. anyone in it or specifically the BSA and I wanted to see how others in the community felt about this behavior my team members are exhibiting.