Sprint Undone Work x Velocity
Hello, all,
Our team has just started using Agile to better estimate our current and future demands.
We use a 2 weeks sprint and we are still monitoring our team performance based on the story points we are able to finish per sprint.
Problem is, for some tasks we depend on other teams and very often we are not able to finish something, not because we ran out of time but because we could not start the task (i.e. task to help consumer UAT tests but they didn't finish the development).
When we close the sprint, these X story points are not calculated in our team velocity, what is incorrect in my opinion. We could have finished those SP and velocity would be much higher.
My idea is to create a task called "Unfinished Tasks" (or something like it) and put the SP for each team member that could have been finished if not blocked by external issues. With this "technique" we will have a better estimate of our team velocity and also to monitor and address the external blockers (i.e. to send e-mails to consumer confirming they will finish development by the time we start our sprint so this doesn't block our work).
I have found one topic on this Forum about this Undone Work in a Sprint where he states:
5. Do not include any effort spent on the unfinished items in the velocity calculation of the current sprint. Velocity is a reflection of your rate of completion not your effort expended.
I agree velocity is a reflection of rate of completion. But in most cases, as I explained, it is incorrect due to external factors.
Thank you for your time.
Adding information: when not including tasks in the sprint numbers that the team could finish, we will have smaller velocity for future sprints.
This is premature optimization.
Think of an analogy of an Auto Assembly plant. The overriding metric is the number of vehicles created by the plant. It isn't the number of doors created, or windshields installed, or engine created.
In the same way, your team's effort is inconsequential to what is truly important in Scrum. How many items can your team actually finish according to your Definition of Done (potentially releasable to production) per sprint?
If your team item completion is being influenced by outside dependencies, don't mask the dependencies by "fudging the numbers" so that you can more accurately measure your team's productivity. It doesn't matter. You're either trying to get credit for work your team completed, trying to assess blame for unfinished work, or simply masking the real issue(s).
To go back to the analogy, it doesn't matter how many car doors your team is able to build, or how accurately you're able to estimate how many car doors your team can create, if no cars are leaving the plant.
Work on resolving the dependency, or have your team only work on items that either have the dependency resolved beforehand, or a high degree of confidence that your team and the outside dependency are aligned for the current sprint.
Why is your team unable to complete tasks during the sprint?
If they are waiting on dependencies, these should be identified early and the Scrum Master should attempt to remove them.
Your example of "task to help consumer UAT tests but they didn't finish the development" sounds like the development didn't get finished, so doesn't sound like an external dependency. The team I'm working with had the same issue and are always working to remove their dependencies or blockers.
I would discourage the use of a task to group your story points. Velocity is used as a calculation for planning and an average velocity from several sprints is usually taken. This will mean your "low" sprint will balance out because the next sprint where you finish the user stories will be "high".
I would strongly discourage "undone" work as part of the velocity calculation. Consider that velocity is all about the amount of Product Backlog turned into a "Done" Increment on average each Sprint. The concept of a "Done" Increment each Sprint is an important concept for the Scrum Team to learn. Tim's analogy of the auto plant is a good one, without all the pieces of the car it isn't "Done".
Think for a moment about how transparency will be lost if "undone" work is included in velocity? The Product Owner uses velocity to forecast a release. How reliable would this forecast be? Empiricism is about making the best decisions based on facts. Regarding the blocked Product Backlog items which are "undone", how can you be sure there is no work left if there is integration and UAT testing left?
Velocity should be tracked by the Development Team for their use in Sprint Planning, and for the Product Owner's release forecasting. That's really it - it is not a measure of productivity.
Problem is, for some tasks we depend on other teams and very often we are not able to finish something,
Does the team know about these dependencies during Sprint Planning? If so, why are they agreeing to undertake work they know they cannot complete to a standard of release quality?