Please login or join to subscribe to this thread
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.
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.
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.
I agree with Sergio.
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?
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.
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?
Please login or join to reply