It's not the same without you


Atlassian Community Hero Image Collage

How can I assess a story/bug done by a developer? Edited

We are working on software development and we use Jira as a means of work management.
As we start a story or a bug, developer will estimate time to finish that story. Ex: Story 1 with 6 points, story 2 with 4 points. Suppose that 10 points are equals to 8 working hour/day. So if Developer X finishes these two story in 8 hours, it considers that they complete their task in a day. 
The case is: When they finish story 1 (the story will start from To do column => In progress Column) and drag it to Checking column. At this time QA or the monitor will check the story. If the story fails with some bugs (EX: 5 bugs), the QA/ monitor will drag it to Not OK column and Developer  X has to take back the story to fix the 5 bugs reported by QA.

The question is: How to assess the story at this time when X has to spend more time to fix these 5 bugs (Even when it takes a half day  to fix only one bug, that means time spent exceeds 6 points as it was assigned from the start). At this moment, how to calculate points for the Story 1 when it takes more time to fix these 5 bugs? Does Jira has any feature to measure this in order to access developer's performance in a story? If X does the story carefully from the beginning, nothing to discuss here. But if he fails the story 1 with 5 bugs, how to monitor and access his performance?

Suppose that 5 days a week he is assigned 8 stories  but 5 out of 8 stories are done with bugs, how to manage his performance? And in a project, if 3 developers (X, Y, Z) are assigned to do their stories, does Jira has filter to see performance of these 3 developers?

Thank you for reading my question! Hope to get your proper answer! :) 


1 answer

1 accepted

0 votes
Answer accepted


Story Points aren't intended to be used to measure an individual's performance or as a time tracking tool.

They are intended to be used as a tool to estimate how many stories can be done in a sprint to aid sprint planning when used with Velocity. When tracking velocity you only count the stories that have been completed and don't have outstanding bugs. So if in your previous sprint you completed 21 points (no bugs) then you know in the next sprint you are likely to complete 21 worth of points.

Bugs are incomplete work. If you start assigning story points to them you will distort your sprint velocity and it will no longer be a useful tool for gauging how much work you are likely to complete in the next sprint.

As story points aren't intended to be used in the way you won't find the features in Jira to do what you do.

It's tempting to use the number of bugs as an indicator of performance but it doesn't provide a true picture. For a typical project, 54% of all bugs are caused by the requirements being unclear or poorly communicated. It's hard to judge a developer's performance when it could be the PO's fault or the tester was having a good or bad day. This why techniques like BDD and example mapping exist to help with the User Story discussions.

If you do want to measure, I would suggest measuring the team and improving the process using the end of sprint retrospective. Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations covers three metrics that do indicate the high performance of a team: lead time, deployment frequency, and mean time to restore (MTTR)

Thank you for your reply. So as for your comment, Story in Jira will not be tested or checked by QA to access the Dev's performance. It is only used to estimate time spent to do a task. If QA found bugs from a story, he/she will have to create a Bug in Isssue type linked to that Story? And at this time Developer can added point to the Bug issue type?

For bugs issue linking is fine but you can also use subtasks to report and track bugs and this has workflow advantages.

The bugs are consider as in complete work from the user story so they don't get given story points. If they were given story points or the original user story points were increased, then this distortst original estimate and artificially inflate sprint velocity. This would make it harder to know how much work the team can do in a sprint.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Agile

Where is my version 1.23 deployed? or How to manage multiple versions across multiple environments?

Introduction In this article we describe the complexity of managing release cycles of complex IT solutions that comprise of a number of Apps, Service and/or Microservices. In particular, we will tou...

531 views 1 4
Read article

Community Events


Find an event


Unfortunately there are no Community Events near you at the moment.

Host an event


Events near you