Skip to main content

Velocity and Story points

Last post 12:58 pm December 7, 2022 by Martin Jungmair
9 replies
06:04 pm November 23, 2022


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?


06:26 pm November 23, 2022

so the team is not cross functional unfortunately.

09:01 pm November 23, 2022

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?

09:58 pm November 23, 2022

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.

10:10 pm November 23, 2022

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.

11:46 am November 24, 2022

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:

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?

07:56 pm November 24, 2022

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!


03:27 pm November 25, 2022

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.

05:20 pm November 25, 2022

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?


12:58 pm December 7, 2022

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.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.