4

I worked in many companies, and whenever the dev process is tracked by the ticket system, there is a big related issue: quality and perception.

When a developer finished 12 points, he or she will be viewed as a super star of the team, but there is way more that is overlooked: there will be 6 to 8 points for other people, probably many people in the company, to encounter, try to reproduce, and report the bug. Then there will be yet another 8 to 12 points, or more, to find out what the causes are, and to fix it.

The total points that got involved, may turn out to be 26 to 32 points or more. Plus, the work, if it was messy to begin with, will accrue technical debt, which may accumulate and multiply over time.

Meanwhile, if a person finished 6 points but is solid, he or she will be viewed as a lagger, a person who can be fired or laid off first. Also, what works well, sometimes people don't appreciate, sometimes just like if you give a meal for the kids on time every time, the kids will take it for granted, while if sometimes the meal cannot be on time and if you deliver a meal on time this time, the kids will appreciate very much.

I think communication only helps a little, because on the manager or other developers' mind, it is still: one person finished 12 points, while the other person only finished 6 points.

How can we solve this quality and perception issue?

5

Measuring individual people by the number of Story Points they complete is an abuse of the metric. That's not the purpose of Story Points; the purpose of Story points is to establish an average Velocity for the entire team. It is a team metric, not an individual metric.

Story points are an arbitrary measurement of how difficult a story is to complete. They are an admission that we all suck at estimation. Accurately estimating time it will take to complete a task requires omnipotence: you need to know how much detail is involved, which requires perfect specifications, and you need to know how your team will respond to that level of detail. The amount of effort expended in estimating such tasks accurately can easily exceed the time required to complete them.

So instead of assigning days, hours or minutes to a task, we assign "Story Points." Story points provide a level of indirection that doesn't bind you to clock time. In our shop, a story point corresponds roughly to two hours, but that doesn't necessarily mean that someone who completed 12 story points expended 24 hours to do it, or that another person who completed 6 story points did less work; it means that our team of four is capable of completing roughly 80 story points per week. That is our Velocity.

Because this Velocity is based on the whole group, it's a reasonably consistent metric, and so can be relied upon to gauge the amount of work that can be accomplished in a given sprint.

| improve this answer | |
  • Tracking the metrics of teams, rather than individuals, does help to deal with variance, but it doesn't really deal with the issue the OP is raising of people only ever doing the smallest possible amount of work to "pass" a single task, even if it will result in problems or additional work in the long term, for the sake of short term praises for completing work quickly. Even entire teams can end up getting the mindset of always creating the lowest quality product they can get away with, because it makes the team look good. – Servy Nov 23 '16 at 21:20
  • 1
    @Servy: I've re-read the question (including the title edit), and I don't think my answer needs to change. There might be some individual performance metric that can be utilized to address the issues you raised, but Story Points is not it. If the manager is using it for that, that means they don't really understand how Story Points work. So it's a perceptual problem. – Robert Harvey Nov 23 '16 at 21:56
  • The question is asking how to effectively measure the work that an employee does. Saying story points doesn't do that is correct, but that still leaves the question of what does work. If I ask how I can fly, and you say, "flapping your hands up and down won't make you fly", that's very correct, but doesn't answer my question. – Servy Nov 23 '16 at 22:02
  • I also feel like pointing out that the OP never uses the term "story point". He may well be referring to story points, but it's also possible his team is using some other type of points. I think story points is quite likely his intention, but felt it was worth mentioning, as there are lots of other similar-ish systems out there that people use. – Servy Nov 23 '16 at 22:03
  • Yeah, I'm not going to be that precise about it; I'm not writing a C++ program here. The likelihood is very high that he's actually talking about Story Points, and he can correct me if I'm wrong. As to not addressing the problem, my advice is this: if you don't know what's wrong, you first fix what you know isn't right. – Robert Harvey Nov 23 '16 at 22:05
4

I endorse what Robert Harvey states in his answer. A person should not "appear like a super star" based on the number of story points they complete. The rating of a developer should not be driven by story points in any way. If they aren't being rated on that metric, then they won't be "tempted" to artificially inflate it. The issue with Robert's answer is while it correctly states that this is an abuse of story points, it provides little guidance on how to correct this other than an implicit "don't do this". This isn't helpful if you aren't in a position to make that decision.

To not put myself into the position of answering a ridiculously broad question, I'm going to focus primarily on story points. I'm also going to focus on more tactical responses as it sounds like you are more like a contractor than a long-term employee. Further, I'm going to focus on what a team member can do rather than what a manager can do. Finally, I'll tend to use Scrum terminology, but it's not necessary that Scrum, or even an Agile methodology, is being used.

Step 0: make sure there's actually a problem. If the system seems to be working, maybe you're just wrong that change is needed.

Given that you believe change is needed, first, definitely do discuss with the team and management what the proper uses of story points are. If tallies of story points completed are a significant factor in promotion, pay increase, and firing decisions, then it will be difficult for team members to change their behavior as it may well be irrational for them to do so in this context. In this case, you will need to point out the issues with using story points as a metric in this way to management, as well as suggest alternative approaches and/or metrics. Bring data from the business if you have it.

This leads to the next facet: subvert the (incorrect) interpretation of story points as an individual metric. There are various factors that should already be happening that can significantly cloud up this interpretation. For example, stories may well change hands during a sprint so multiple developers are involved: who gets the "credit" then? This should certainly be happening at least once for QA. Pair programming or code reviews as well as design meetings also make it difficult to completely assign credit to a single individual. These sorts of practices should be encouraged. The idea that a developer "owns" a story should be discouraged (which is not to say you shouldn't keep track of who is currently working on a story). Stories should be left unassigned until someone starts working on them. It should also be a completely reasonable behavior for a team member to say "Story A has turned out more complicated than we thought, can someone take Story B that I've partially completed?"

If you are recognized, by at least the team, as a "better" developer (the team usually has a good idea of the actual merits of the members) and/or you are a de facto leader of the team, generously recognize the contributions of others on stories you've worked on, and de-emphasize your own contribution to "your" stories. Emphasize priority order over number of story points, even within a sprint. While the stories within a sprint should be addressed in whatever order is most efficient, you should still bias towards higher priority stories. By your words and actions, you should communicate that completing higher priority stories is more important than completing stories with more story points. By definition, higher priority stories are more important to the business, and, by definition, more story points only means more difficult to implement regardless of value to the business. Generally, you should be emphasizing optimizing for business value.

In a sprint retrospective (or equivalent), it should be frankly discussed whether stories were over- or under-estimated for the purpose of improving estimation in the future. To the extent that story points completed are still being assigned to individual developers, wide disparities between team members should be viewed as failures of estimation (especially when combined with the team's understanding of the relative skill of its members). If poor quality results are getting through, then this is a failure of process. This should be discussed frankly and steps should be taken to mitigate it. That said, it usually doesn't make sense to "name names" as at least two people must be involved, the person writing the poor code and the person QAing that code, and ultimately it's a failure of the team as a whole. In a Scrum context, this may mean you need to adjust your "definition of done" or make sure you are adhering to it. Lower quality work, though, is not necessarily poor quality work. Quality is a cost/benefit trade-off, and you can definitely be overly conservative.

| improve this answer | |
0

To solve the bigger problem you seem to be describing - how to credit to everyone on the team, not just the final coder that fixes it - I think you want to have systems in place that publicly reward everyone and that focus on the team communication and advancement such as:

  • Including all team members in standup and in the various weekly agile meetings
  • Highlighting of contributions by all, not just programmers
  • Dignity and respect for all team members, regardless of position
  • Fun times when people can get to know each other better personally
  • Have all team members present during retrospectives
  • Have all team members sit together
  • Weekly team meeting
  • Regularly scheduled 1:1's both within teams and also across teams and levels
  • Hiring good workers but not ninja rockstars with big egos

It's also a reasonable expectation of employees in most companies that there are many people in those companies who don't code but are still essential to the business. The key part of your question seems to be centered on how to give such people credit.

| improve this answer | |
  • While these all seem like good ideas, how do they address the problems of company metrics often incentivising poor behavior? – Servy Nov 23 '16 at 21:25
  • @Servy: The op never mentioned anything about laggards. – Robert Harvey Nov 23 '16 at 22:06
  • @RobertHarvey I don't understand your comment. – Servy Nov 23 '16 at 22:09
  • Really? Is the problem "laggards," or no mention of them? – Robert Harvey Nov 23 '16 at 22:09
  • By doing all of these practices you are letting folks know that you measure and count on these things. I think of quality somewhat similarly to security - no easy few fixes but more a culture of doing the right thing. Failure to do the things I list will tend to lead to the developer rockstar fixer in my experience. – Michael Durrant Nov 23 '16 at 22:11
-1

You have a problem from the start.

"Story points" should be assigned for completely finishing the story. There is the time for finding the cause of a bug, if the story is a bug fix, or the time for design otherwise. There is the time for writing code. There is the time for reviewing the code. There is the time for testing the code. All that has to be included. So a story that is very easy to develop but hard to test will have lots of story points.

| improve this answer | |
-3
  1. Eliminate the managers with this perception: they should not be managing software.
  2. Educate the developers.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.