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

Question

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 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?

Answer 1

A common theme in Agile Software Development, and especially in Scrum, is the idea of a cross-functional team. There is no concept of an engineering team finishing something on Friday afternoon and then handing it off for testing later. The team, as a whole, does all of the design, development, and testing necessary to complete the work. This doesn't mean that you may not have specialists, but you would take a whole-team approach and eliminate hand-offs.

If you are appropriately sizing the work and developing the skills to get work done across all of the team members, there's absolutely no reason why you cannot design, develop, and test work in one Sprint. Get to the state where the team can do that.

Answer 2

I think you may be asking the wrong question.

In my experience, it doesn’t work - still, tasks cannot be fully developed and tested in one sprint.

From a scrum perspective, I'd say the key question may actually be "Why can't tasks be fully developed and tested in one sprint?"

Have you brought this question up in retrospectives? Have you tried the "5 Whys" technique on it, or some other approach to probing for the root causes of a problem?

I do understand that it seems like common sense, with development wrapping up at 5pm on Friday, etc. But often, "common sense" has a number of assumptions hidden inside it; and some of those assumptions are true in waterfall, but are actively rejected by Scrum. This is one reason that some people talk about an "agile transformation" - it really does take time to spot all the assumptions and practices that are not consistent with Scrum, and figure out what to do instead.

For example... why is development wrapping up at 5pm on Friday, instead of at 5pm on Thursday so the work can be tested on Friday?

I would also invite you to consider the assumptions you are making here:

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 dashboards and charts will be way off.

That is, why do you conclude that the dashboards and charts are way off, rather than accurately telling you what the team's velocity is? What is your definition of team velocity? What do you (and your organization) use it for? Is that the same thing that Scrum advises you to use it for?

I hope this is helpful, even though it is probably not the kind of answer you were looking for. :) Good luck!

Answer 3

Two of the key components in Scrum are the Product Increment and the Definition of Done. Every Sprint, the Scrum Team should deliver an Increment that is Done - i.e. it is a potentially shippable product that provides some kind of value to the customer. This implies that work doesn't get marked as done until it is Done-done, because a feature that is untested shouldn't be shipped, and hence can't be removed from the Product Backlog.

Of course, you don't want the Developers (which refers to all members of the Scrum Team other than the Product Owner and Scrum Master) sitting around doing nothing, so the aim should be to keep everything moving along as much as possible and ensuring that there is always work for people to do. This could involve:

• Splitting stories up into smaller components to reduce the lag time between starting to code the feature and starting to test it;

• Use techniques such as Behaviour-Driven Development so that testers and coders are working more closely together throughout the Sprint;

• Reducing the amount of specialisation in your team so that there aren't clear "coder" and "tester" roles. Instead, try to have it so that Developers work across writing, reviewing and testing the code as much as possible.

If all of that fails to help, then there are things that Developers can be doing that don't directly contribute to the team's velocity but which can help the team be more productive in general. These could include:

• Helping the Product Owner review the Product Backlog by refining stories and making them ready for potential inclusion in the next Sprint;

• Making note of any skills or knowledge that could be helpful in an upcoming Sprint and doing something to bring it into the team (e.g. enlisting the help of an expert for Sprint Planning, or doing some self-development).

Answer 4

1. Development teams consist of software developers, testers, and other roles that contribute to a story in a sprint.
2. The story points are generally given to the stories by playing "planning poker" with every development team member.
3. At the end of each sprint, the scrum team should present the completed stories and get acceptance for the stories.

So;

1. If you make the software development of a story, you should test it in the same sprint too.
2. There will be stories to code hard but to test easily, or to code easily and test hard; "planning poker" with every team member solves the "leveling of story points" problem.
3. For assigning and granularly managing the stories, tasks/subtasks can be used.

Answer 5

"Short" answer:

Increase Sprint Length.

It's never mentioned anywhere, but have you tried increasing the Sprint length up to, say, a month? As your question is structured, it may mean you're using weekly Sprints and it simply isn't working. I'd guess you'd have freedom to experiment with longer Sprints, otherwise you have more challenges on your agile journey than you may think.

---

Assuming tweaking Sprint length was already explored and discarded...

There are two very different problems you're trying to tackle:

• How to make Dev + Test to work
• How to make Jira reflect the info you want

In the way you framed your question, you may have a X>Y problem. You're trying to get the Jira data to make sense so that you can implement Scrum properly... and that may be increasing the complexity of your agile adoption.

Asking from both organisation and Jira perspectives:

Organisation aspect: You can either have a team with Dev + Testers or a Scrum team. Not both.

This might generate a lot of discussions, but that's my take on Scrum. Several places have different partners or vendors for dev and testing and it's virtually impossible to embrace Scrum values with such a structure. I've worked with teams like this in the past and helped on the journey towards reducing the amount of testers so that we moved from a team with 30% testers (planning executing the tests) to a team with a single QA person (assisting the development team to plan tests properly using strategies like 3 amigos and feature mapping) to teams with only developers. Anything around trying to embrace Scrum without an empowered team is lip service.

Jira aspect: You can have two different boards to measure velocity.

Disclaimer: this is NOT agile. Use this information with discretion. I really like Jira, but I also understand that it oftentimes leads people to solve the wrong problems. One alternative is to have a secondary board where the last column is the "ready for test" status, for instance. One of the most common misconcepts on Jira usage is that a ticket is considered done from a board perspective only when the jira is in the status done. That's not the case.

Example: Assuming you have in your board the columns:

• To Do
• Prioritised
• In Dev
• In Review
• Ready for Test
• In test
• Done

You can have one (Kanban) board from To Do to Done and one Scrum Board from To Do to Ready for Test. The Scrum board's sprints and velocity would consider the items as "completed" as soon as they reach its last column (i.e. Ready for Test).