-1

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?

2
  • 2
    This seems a bit all over the place. Can you explain further what exactly the problem is you're facing and how you're trying to organize your tasks?
    – Erik
    Oct 16 at 18:51
  • "Assume the engineering team finished big task on Friday 5pm - obviously it won’t get tested until next week". If it's not tested, it's not finished.
    – Blueriver
    Oct 20 at 20:47
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!

8
  • Vicki, thank you for your answer. What you're describing makes sense, but I don't understand how to actually implement it. Developers work till end of Friday just as everyone else - thus their feature will not be tested in the Sprint. Jira doesn't count SP unless the User Story is marked as Done, and thus the velocity will be off. I feel that I'm close to the solution, but some detail is missing.
    – user48230
    Oct 17 at 16:28
  • "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?" - let's say they will finish on Thursday, so what will they do on Friday??
    – user48230
    Oct 17 at 16:32
  • @user48230 That's the 100% utilization fallacy. The goal isn't to keep people busy; the goal is to deliver increments of value on a dependable cadence. You have implemented the wrong goal.
    – Todd A. Jacobs
    Oct 18 at 14:35
  • 1
    @user48230 No. In a Scrum environment, the "value" being delivered on Friday is the demonstration/review with the stakeholders, not "more work." If no one else takes this into account, I'll write a longer answer when I can. Value in Scrum isn't about busy-ness; it's about consistency, quick feedback, and collaboration.
    – Todd A. Jacobs
    Oct 18 at 17:10
  • 1
    @user48230 I think the problem is that you're thinking of this as Dev -> QA, but in an effective agile team it's more like (QA <-> Dev) -> CI, where the developers and testers are collaborating throughout the process. If you have I-shaped people, then you really ought to focus on a test-first rather than a dev-first process. Even if you stick with your current process, which I'd argue against, you ought to have the developers working on the demos, documentation, toolchain improvement, or tech debt if they have nothing else to do. There's never "nothing to do" in Scrum!
    – Todd A. Jacobs
    Oct 19 at 17:25
3

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.

1

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).

0
  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.
0

"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).

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.