Trying to understand manager's view of story points delivered vs quality
Today I was discussing with a colleague a previous bad experience with an "acting manager" from a few years ago.
The project was a re-inventing of an existing product to move away from technologies that would soon become obsolete / unsupported using new technology not yet familiar to most of us in an understaffed team.
At a point in time I made the honest comment that I was struggling with some aspects. Over time I was improving with things.
A few months later I was taken into the meeting room by the manager for what seemed like a normal friendly chat. Soon that became a discussion of my under delivery on story points when compared to the other 2 guys. So they were hitting 20 points, me 15.
The fact that their delivered work had more bugs raised than mine was considered irrelevant, including the fact that one guy rushed his stuff so much that, after a slew of bugs were raised his area of work had to be re-developed - twice (i.e. code written 3 times!). If I had rushed through to deliver the same story points as the other guys that would be fine, even though more bugs may be raised.
Much unpleasantness ensued over the next few months, highlights including the admission from the other guys that their stuff didn't work and was worth 0 points, whereas my stuff was fine - the manager refused to acknowledge their admission of failure and only see my under delivery.
So I want to get this forum's take on this. Which is better - lots of points delivered + lots of bugs raised, fewer points less bugs ?
I think that the entire team is responsible for quality. So a statement like this concerns me a little:
discussion of my under delivery on story points when compared to the other 2 guys. So they were hitting 20 points, me 15.
Measuring individual velocity is not a good way to measure the effectiveness of a team, as the entire team should be responsible for completing the work.
Also, one of the Agile principles is "working software is the primary measure of progress". Regardless of the team's velocity and number of bugs, they should aim for working software.
So to answer your question, I think that points delivered is not a good metric for quality. Less bugs is one way to measure working software.
So I want to get this forum's take on this. Which is better - lots of points delivered + lots of bugs raised, fewer points less bugs ?
Which would you say describes an actual outcome, rather than an output?
Have seen an almost identical scenario. I wish I could say I was brave/smart enough to address it when first noticed. Took me a few good months to find the courage, diplomacy and drive to approach a very senior individual and ask them something something along the lines of:
You pay $$$$ for a product in your wishlist: would you rather have it with zero (or insignificant) bugs or full of annoying problems?
Quality, I explained, should be the driving force behind development initiatives.
They didn't get it though. To them it made more sense to see who is productive, and who isn't. Story points completed weighted more than value/quality. Though they opted for A (saying they'd prefer no bugs), they stated buying a product was different (in action, scope, analysis) than developing one.
¯\_(ツ)_/¯
Hi Ian,
"Which would you say describes an actual outcome, rather than an output?"
In the context of an understaffed team of 3 working on a project that seemed large (500+ user stories)
- Lots of points delivered is an output
- Fewer points delivered is also an output
From 1. Outcome is buggy software giving a non-value adding delivery in the form of not fit for purpose software leading to unhappy stakeholders.
From 2. Outcome is fit for purpose software leading to satisfied stakeholders.
The issue of an understaffed team is not the developers problem / fault.
Hi Eugene,
All the manager was interested in was lots of points delivered.
Unfortunately it deteriorated and the team felt damaged by the manager. In total contrast the next place I worked at did Scrum well and preferred things taking a little longer with higher quality and always appreciated my input at any stage (25+ years experience must count for something !).
I also faced something similar but I wasn't a developer. I was Scrum Master and I was confronted about if I was responsible for the teams performance, why wasn't I pushing each developer to complete more points. My response was that a team completes work not individuals. And that the team is self-managing and if they choose to have one person completing less "points" then I am doing my job.
I also explained in great length how points are the worst measure of productivity. Points are guesses based on what they know at the time they guess. When they start working, new information can make things easier or harder. As an experiment, I asked the team if the manager could join their team for a couple of sprints. The manager had development experience and was able to do the work. I tracked the manager's point completion. As you expected, they completed the fewest points on the team. And prior to becoming manager for the team, they were the developer that wrote over half of the code for the product the team was supporting. I asked the manager how accurate they were with their estimates and they reluctantly agreed that they were wrong in every one of them. I then asked if they still stood by their original complaint. They never answered that question but instead said that they were late to another meeting and had to leave.
One problem I see with my scenario and yours is that it appears each person is working on a story by themselves. While I admit that the teams get to self-manage their work, it is always my practice to coach that if applicable "mobbing" on a story usually produces faster completion, better understanding by the whole team of the work done, and often in less defects that have to be fixed due to multiple authors (much like paired programming). And when this practice is used, there is no way that anyone can be judged by the number of points that are completed.