Velocity and Story points

so the team is not cross functional unfortunately.

However, I want that within my team, we do our best.

What does "best" look like, and is there consensus on this? For example:

• Should each team member be kept busy doing stuff, which seems to be the PO's ambition
• Should the team provide velocity in lieu of value, which seems to be your hope, or
• Should the team leverage empiricism and teamwork by learning to build the right thing at the right time?

that sounds very “ideal case” or what the books says. The reality is often very different. I need to sell it, to the PO and to the team. Speaking about abstract things does not work here.

My advice is to forget about abstract things altogether. Sell Scrum on the basis of empiricism, and the valuable outcomes which ought to be expected from it. You can't get more concrete than that.

Instead of trying to convince your PO, what about trying to meet them where they are and start from there? Identify some of their pain points and offer up how the Scrum framework may help. Tie back to empiricism as Ian mentioned. Transparency, Inspection and Adaptation is powerful on its own and Scrum simply provides a structure and cadence for it.

How might you hold up a mirror to your PO so they can see the reality of the current situation more clearly? Does starting more work, actually help the team finish more? Or is it creating a traffic jam of unfinished work? This resource utilization trap exercise is a great way to demonstrate: https://www.youtube.com/watch?v=CostXs2p6r0

Do you have data that you can use? How many Backlog Items are completed in a given time period? Are they valuable items? Is the team achieving their goals?  

Do you have empirical evidence to support the POs concern about the team having "nothing to do"? How often has that actually occurred? What were the reasons? How might the team address those causes?

The thing is the following: Our stories have a lot of dependencies difficult to face and mostly out of the hands of the team, the PO and the scrum master. Like external dependencies, sickness or the fact that we are borrowing a host developer because we dnt have one right now in the team or dependencies with other teams (this last one is the only one that can maybe be improved by bringing it to the SoS) or the fact that some stories depend on others and obviously if one does not move, the another one either…

This results in a lot of stories are not closed at the end of the sprint, not because the team did not work, but because of all these dependencies…

The team is also not cross functional and works in silos. First because there r external employees, who cannot do pair programming or other tasks apart from that clearly stating in their contract, and secondly, because some topics are sooo espefic, that sharing knowhow within the team either would not make sense or it would simple be impossible.

How can we better address this?

Would make sense/make any difference separating the backlog the stories that are mainly external or stating somehow in the backlog those stories that have external dependencies?

I mean, the team is obviously aware of this, and the PO too, but maybe at the end of the sprint we would see clearly some stories closed, which might potentially increase the motivation of the team, and also increase transparency by showing what was not completed, mainly external things, so that the PO sees that actually the team is working well and I can bring this “picture” at a program level, so that they see the issue with these dependencies and maybe do something?

Any thoughts on that?

Thanks so much!

JFB

Perhaps you could benefit from completing a value stream mapping exercise to identify and illustrate the entire development system including any upstream/downstream systems and other team dependencies. 

I also work for an organization where we have outside of team dependencies. One example is our API micro services team. We depend on them as our interaction point with backend administration systems. One day I hope we can bring this function into our teams, but until then we need flow like water around the constraint. When we are doing backlog refinement we note any dependencies with other teams and in our case we use links in Jira to connect between backlogs. This helps with transparency and we can easily inspect progress and adapt accordingly. Dependencies are considered when the Product Owner is ordering the backlog alongside value, size etc. We prioritize work we can bring to Done over work we can only get started with.

we use azure Devops not Jira. What about the stories that have depencies, create a new status called “waiting” when the team this its job but what is pending depends now on external people? I think this would bring some transparency at least…

I had thought too about dividing the story in “team” and “extern” so that the team can better focus on what is in their hands and also I think that seeing completed stories helps to imcrease motivation, but I like more the option mentioned above, maybe not that “transparent” but at least the backlog is cleaner, not so big.

Any thoughts?

Saludos,

I had similar issues in a team in a former company. They had dependencies to external companies and we struggled a lot to finish stories until the end of the sprint. 

Some of the tasks have been moved in front of the sprint so we were able to do the ticket within a sprint. But it was not able for every ticket. Splitting in external and internal is an ugly solution as you do not create value for the customer at the end of the sprint just by doing the internal tasks. 

If you have dependencies only within your company, address this in your organization that your team can also do the other tasks or you get somebody into your team who can do that so you are close(r) to the customer. Do not try to workaround using some ticket status for an organizational problem.