Average story point burned
It's a tricky question. Is it correct to talk about an improved average of burned story points by a certain percentage?
Preface: We know the mission is to deliver value, but it's not always possible. In an ideal view of the work as a Scrum Master and of a Scrum team, it is, but many times we have to adapt to a compromise between what we want to do and what we are asked to do, or what is possible due to external factors. An impediment from a dev team member slows down the sprint, and the whole team can't produce the increment set as a goal.
Question: At this point, is it correct to talk about a percentage of achieved story points as something valuable? For example, in a resume or a report. "After 6 months of work, the team, from an initial 45% completion rate, reached 75% of burned story points."
If we take the data as it is, it looks good and is pleasant to share. However, a team that achieves 75% completion never fully produces the initially set increment.
Therefore, can it be a data point that provides added value? Am I implicitly saying, in a context where I'm showing improvement, that my team doesn't reach 100% of the set goal?
TL;DR
Is it incorrect to write on a resume or report "achieved 75% of burned story points from an initial 45%" because I'm essentially saying they don't reach 100%, or is it still an important piece of information that I should share?
But above all, is achieving 75% of burned story points in one sprint a good value? In your experience, with the teams you've worked with, was reaching 75% seen as a good thing or merely falling short of the originally planned 100%?
The only purpose of estimation in Scrum is so Developers can get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control.
When empirical evidence of value isn't there, we have a potential source of embarrassment in a company.
One option, and the preferred one in Scrum, is to bring the problem to daylight as rapidly as possible so it can be dealt with. If there are systemic organizational impediments to be overcome, we ought to highlight and explain them to senior leadership, and then actively engage with them in finding a solution.
Another option, which is far more common, is to cover the problem up with a sanctioned process of some kind that makes things look OK. Stakeholders might be given story points to suck on, for example, while their leap-of-faith is spun out beyond the Sprint. The burn-down is actually showing their investment going up in smoke, but because they want to believe, we might actually gain their complicity in this racket. If the higher-ups in any company want points, I've got a million spare right now which I will gladly sell for a dollar each.
Not going to comment on "correctness", but I wouldn't do it.
Why?
Points do not provide value to customers.
Imagine if the company you worked for offered to compensate you with “pay points” instead of paying you cash. The pay points cannot be redeemed for anything, but you will get lots of them. Which would you take?
Reaching a certain number of story points doesn’t demonstrate value delivery. Increasing by a number of story points doesn’t demonstrate improvement. Achieving Spring Goals, delivering usable increments of value does.
At Sprint Review you share the results of the Sprint. You may not achieve the Sprint Goal, but you could still create an increment of usable value and share that. You could share any challenges you encountered. You share progress towards the Product Goal. These are tangible things. Story points are not.
A few other things to consider.
The Sprint Goal is an objective. Some sort of desired outcome that provides value. It isn’t associated to points and it isn’t associated to “burning” a number of points. We don’t deliver points to our stakeholders.
Setting a defined increment as a Sprint Goal may also be limiting. As soon as a backlog item meets the Definition of Done, an Increment is born. Consider separating the two.
Thanks for the replies, but I think the focus has been, partially, lost.
As I was saying, we don't always find ourselves in the position of being able to apply scrum as best as we would like. Personally, for example, I work on projects that are apparently defined as applying scrum, but in reality they are full of waterfalls and micro management.
These are projects where, although a sprint goal is estimated and the activities weighed, in an approximate manner, 100% is never reached. It's also true that since I've been inside, I think I've managed to do a good job, bringing the completion percentage to 75%. The fact is that the data is important for those who read it. If I go and report it in an internal report, for people who say they do scrum just because it's cool but in reality they don't do it, it might even be seen well.
I wonder if this data, in a CV, is something of value. Because again, everything revolves around who views this information. A stakeholder in my project could see it well, a hiring manager from another company, more accustomed to Scrum, could read about the inability to reach the objective.
Your original question was whether showing a % of points improvement was something that would be good for a resume. Unfortunately, it might be because so may people have a misconception about what Story Points mean. They believe that "burning points" actually means something. But as the previous responders have said, they really have nothing to do with showing success. I recommend you read this article by Ron Jeffries who is said to be the inventor of Story Points.
Personally, I never mention story points to anyone outside of the team that is using them. I do not advocate for anyone to use them but will support the use if the team wants to use them and understands their use. For anything outside of the team, I reference their ability to deliver usable increments of value to the stakeholders and their success as using feedback obtained from the stakeholders to adjust the current product to deliver upon the stakeholders next desires.