Velocity and Story points
my team is a very reluctant to scrum and the fact that the PO is also not convinced makes it a little bit complicate. It is also not agile 100% at a program level and this makes that the team also does not take it so serious…
However, I want that within my team, we do our best. How can I convince a PO who prefers to create very ambitious backlogs in the sprint planning than based on velocity because he is concerned that when the team completed all the stories, does not have anything to do? Here relevant to consider, to understand his point of view, not all the team members can work in all the stories, they work in silos… so he prefers to add more stories so that they have always something to do.
We also have dependencies with other teams and the fact that very often the stories depend on one person from my team, does not make it easier either.
This results on unfinished stories postponed to the next sprint.
How would you address this and convince him and the team of the benefits of the velocity and so on?
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!
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.