Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum, Stakeholder Management
How do you calculate velocity in scrum when you have outside stakeholders?
I work for an ecommerce/publishing company. In the last few years, we have started to organizationally adapt agile. Our biggest issue with setting a project roadmap or predicting when our products can hit the market is our outside stakeholders. We have over 30+ contributors to our products that submit and review content. We have re-worked contracts to motivate them to turn their work in on time but it doesn't always work. We also have a ranking system to weed out and not work with the ones who submit poor quality work. We still have unpredictable release cycles and this is our major issue. I'm just not sure how to consider this in our velocity calculations.
Sort By:
Page: 1 2 next>
Hello Alicia, in my opinion the roadmap it is just an estimation, it does not mean that the team is going to be able to deliver the product in that time, the velocity of the team could be adjust each sprint taking in consideration the feedback of the restrospective meeting. Agile is about that, inspect and adapt.
Alicia

In agile velocity is the amount of work done during a sprint. In agile, velocity provides the distance your team travel to reach to the sprint objective.Once you know the velocity of past three or four sprints, calculate the average of them and make a prediction.
But I have doubts regarding your statement " they are external stakeholders" so are they part of the team ? Do they estimate the amount of effort and decide what work they are capable to do in the spring? They are external workers ? If they are, you have dependencies in your project what complicate any kind of prediction.

As Yenny said velocity can vary from spring to sprint, probably you should estimate the average of last sprints and use that as reference.
See also the average of the poor work refused by sprint to include a comfortable risk tolerance.

Alexandre
...
1 reply by Alicia Pino
Feb 11, 2020 12:20 PM
Alicia Pino
...
Thank you for your response. The outside stakeholders are physicians that we contract with to write and review our content. They are not technically apart of the team and do not participate in standup, planning or retrospectives.
To "predict" a roadmap the important thing is sprint duration, not velocity. Some people takes velocity as a meassure to estimate and that´s wrong. On the other side, I work in agile environments with outside people. The problem you stated is because they are not part of the team. They are part of the group but not the team. it is a matter of commitmmnet which is a key attribute if you are using a framework like Scrum.
If they are truly external, as in not part of the team, they are then a dependency. Velocity is calculated within the Scrum team. If work is handed off to an external team, that would be calculated separately from the team, though still incorporated in the release plan. This will showcase other opportunities for potentially bringing some of this talent internal. One of the goals of the Scrum team is to have all that is needed on the team to complete the work, avoiding handoffs that bring inherent risk and unknowns, as you are clearly feeling the effects.
...
1 reply by Alicia Pino
Feb 11, 2020 12:26 PM
Alicia Pino
...
Thanks for your reply and insight. Unfortunately, with the nature of what we publish, bringing all of our contributors in house isn't a reality. We publish textbooks for physicians studying for their boards. Our contributors are practicing physicians within 16 specialty fields such as surgery, nephrology, neurology etc. They review and edit our content and then we copyedit and publish.

We do calculate their turn around times based on what is stated in the contract but we have two major issues with this 1.) frequent requests for extensions despite contract lines that provide bonus for early or on time delivery and 2.) what they edit, write or contribute is either poor quality or an extensive amount of work.
I agree with Sergio.
Alicia -

It sounds like you don't have a "whole team" from a delivery perspective, which means velocity or any other method of estimating throughput is going to be unreliable. This is the same as having core team members who don't have predictable allocation to the project.

It is one thing if a very small number of work items in the release backlog have such external dependencies, but when it is the rule not the exception you need to find a way to get better engagement and predictability from these stakeholders.

Are you scope bound or time bound?

If your customers will accept varying amounts of features delivered per release, then why not fix the timing for the releases and let scope be the variable?

Kiron
...
1 reply by Alicia Pino
Feb 11, 2020 12:38 PM
Alicia Pino
...
Thank you for your insight. We are mostly scope bound, and even then it is flexible based on market requirements or new updates. The release date of our product is always flexible but that also seems to be the issue. When we predict an October release, our other departments plan their work accordingly. We update that release estimate throughout the year and adjust accordingly but it still seems to be a leading frustration.

We publish both print and digital books. I'm pushing to publish our digital book quarterly to help avoid some of this snowballing of overdue work pushing the overall publishing deadline out for our customers.
Feb 11, 2020 2:59 AM
Replying to Alexandre Costa
...
Alicia

In agile velocity is the amount of work done during a sprint. In agile, velocity provides the distance your team travel to reach to the sprint objective.Once you know the velocity of past three or four sprints, calculate the average of them and make a prediction.
But I have doubts regarding your statement " they are external stakeholders" so are they part of the team ? Do they estimate the amount of effort and decide what work they are capable to do in the spring? They are external workers ? If they are, you have dependencies in your project what complicate any kind of prediction.

As Yenny said velocity can vary from spring to sprint, probably you should estimate the average of last sprints and use that as reference.
See also the average of the poor work refused by sprint to include a comfortable risk tolerance.

Alexandre
Thank you for your response. The outside stakeholders are physicians that we contract with to write and review our content. They are not technically apart of the team and do not participate in standup, planning or retrospectives.
Feb 11, 2020 6:50 AM
Replying to Andrew Craig
...
If they are truly external, as in not part of the team, they are then a dependency. Velocity is calculated within the Scrum team. If work is handed off to an external team, that would be calculated separately from the team, though still incorporated in the release plan. This will showcase other opportunities for potentially bringing some of this talent internal. One of the goals of the Scrum team is to have all that is needed on the team to complete the work, avoiding handoffs that bring inherent risk and unknowns, as you are clearly feeling the effects.
Thanks for your reply and insight. Unfortunately, with the nature of what we publish, bringing all of our contributors in house isn't a reality. We publish textbooks for physicians studying for their boards. Our contributors are practicing physicians within 16 specialty fields such as surgery, nephrology, neurology etc. They review and edit our content and then we copyedit and publish.

We do calculate their turn around times based on what is stated in the contract but we have two major issues with this 1.) frequent requests for extensions despite contract lines that provide bonus for early or on time delivery and 2.) what they edit, write or contribute is either poor quality or an extensive amount of work.
Feb 11, 2020 8:13 AM
Replying to Kiron Bondale
...
Alicia -

It sounds like you don't have a "whole team" from a delivery perspective, which means velocity or any other method of estimating throughput is going to be unreliable. This is the same as having core team members who don't have predictable allocation to the project.

It is one thing if a very small number of work items in the release backlog have such external dependencies, but when it is the rule not the exception you need to find a way to get better engagement and predictability from these stakeholders.

Are you scope bound or time bound?

If your customers will accept varying amounts of features delivered per release, then why not fix the timing for the releases and let scope be the variable?

Kiron
Thank you for your insight. We are mostly scope bound, and even then it is flexible based on market requirements or new updates. The release date of our product is always flexible but that also seems to be the issue. When we predict an October release, our other departments plan their work accordingly. We update that release estimate throughout the year and adjust accordingly but it still seems to be a leading frustration.

We publish both print and digital books. I'm pushing to publish our digital book quarterly to help avoid some of this snowballing of overdue work pushing the overall publishing deadline out for our customers.
Velocity is a backward-looking measure that can be used for forward-looking estimating, but it's still an estimate. You are wanting to use the size of the total effort divided by the velocity to determine the number of sprints, hence when you can expect to release. You can establish your team's velocity based on the work they have performed. You can estimate the release based on the work they will perform. The variable is waiting for content from external sources.

Is this a fair assessment?

Do you have enough historical information to be able to estimate the expected delay(s) due to external dependencies? One approach might be to create a spike/story for expected delay. How you size this story would vary based on the length of the expected delay and the length of your sprints. I'm not saying this is the best way. The point is to plan for the delay - it's a risk that you need a mitigation plan for.

Does this make sense? Am I missing anything?
...
1 reply by Alicia Pino
Feb 11, 2020 2:49 PM
Alicia Pino
...
I really appreciate your clear break down and tactical approach. I'm going to take the spike/story to our production department lead and talk through it to see if it's a feasible solution.

We don't include our outside contributors into our velocity estimating but we have to somehow account for their time and delays.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Would you tell me, please, which way I ought to go from here?" "That depends a good deal on where you want to get to."

- Lewis Carroll

ADVERTISEMENT

Sponsors