Skip to main content

How do I manage development with testing and get proper reporting in JIRA?

Last post 05:26 pm October 18, 2021 by Daniel Wilhite
5 replies
05:08 pm October 16, 2021

The key question goes back to estimation of User Stories.

I believe that combining testing and development Story Points in one Jira user story as separate tasks doesn’t make sense, as it is like combining apples and oranges.

Specifically it doesn’t allow proper estimation of Velocity. Assume the engineering team finished big task on Friday 5pm - obviously it won’t get tested until next week and the development SP won’t be accounted in the sprint - JIRA doesn’t count SP until the Story is moved to done - thus development SPs won’t be counted and thus velocity, dashboards and charts will be way off.

I already foresee a bunch of comments re: automated testing, etc. In my experience, it doesn’t work - still, tasks cannot be fully developed and tested in one sprint.

As of now I’m separating Q/A from development - points count once development is completed, but this approach also doesn’t feel right.

Any ideas?

05:33 pm October 16, 2021

tasks cannot be fully developed and tested in one sprint.

There's your problem. Why not?

12:56 am October 17, 2021

points count once development is completed, but this approach also doesn’t feel right.

You're correct that isn't the right approach. Velocity is the amount of Product Backlog turned into a Done Increment in a Sprint, on average. If your stories are not Done, and yes Done includes QA, your velocity is ZERO. 

There's a reason why having a Done Increment is so important and essential to the empirical process. Done means the increment is usable and transparent. 

It appears that dashboards, charts and velocity being way off are not the real issues. If you want to use Scrum, then your Scrum Team will have to work through Ian's question.

PS. Velocity doesn't have to equate to story points. Velocity could be the number of PBIs completed in a Sprint, on average. But the PBIs added to the Increment have to meet the Definition of Done.

05:47 pm October 17, 2021

Given that you are asking about reporting, perhaps there is some kind of need in the organization, or with the stakeholders, related to trust.

Perhaps there isn't a high level of trust for the Scrum Team, or a manager seeks extra information in order to reduce risks, or perhaps the Scrum Team see an opportunity to gain more autonomy through showing that they are doing a good job.

In that case, I recommend this 9 minute video (you can skip to 1:04 for where the conversation gets really relevant).

If you watch, you should see how it connects to the answers from Ian and Chris.

06:55 pm October 17, 2021

Assume the engineering team finished big task on Friday 5pm


Probably having the team find the reason for this situation could get them a solution. Like to point out from the guide, 

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

05:26 pm October 18, 2021

I have worked with teams that did no automated testing and were able to get the coding and testing done within the same Sprint.  As others have said, the thing you should be focusing on is why your team can't do that. 

You make it sound like you have a completely separate team that does all of your testing that you have to hand off work to.  In that case your Definition of Done should focus solely to the things that are within your team's ability to do.  It will allow you to have a "done" increment at the end of your Sprint. 

Having said that, I think that is entirely the wrong way to deal with this.  Because having a separate team test something that you have considered to be "done" will most likely result in rework for your team as the test team uncovers defects.  You never mentioned what role you play on the team but it really doesn't matter since you are making decisions for the team which is anti-Scrum and anti-agile anyway. 

You need to talk to the team and find out why the dev and test can't occur within your sprint boundaries. That is the real problem you have.  Your solution is going to give a false sense of completion.  

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.