How do I manage development with testing and get proper reporting in JIRA?
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.
tasks cannot be fully developed and tested in one sprint.
There's your problem. Why not?
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.
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.
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.
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.