“How should this feature be broken up into tickets, PRs and deliverables?”

It’s a question that most scrum development teams ask every sprint. What works for one team may not work for another team. However, establishing some guidelines and daily practices can provide enormous benefits, especially for medium-sized development teams (4-9 people) that consist of engineers with a wide range of skill levels and skillsets.

By having the team agree to follow an established procedure, less time and decision-making is needed each sprint for the boring stuff like ticketing and tasking. I have seen the following standards promote an agile mindset that allows developers to more easily hop on subtasks throughout the sprint cycle. They also put an emphasis on closing out the sprint and making QAs life as easy as possible. This process assumes that the team has dedicated QA resources and utilizes an agile friendly project tracking software like Jira.


  • To eliminate confusion around when or if a developer is able to hop on a sub-task for a parent ticket that someone else has already started.
  • To eliminate confusion around what and when something should be tested and released.


  • Every parent ticket / feature should correspond to a feature branch that is tested by QA.
  • Every subtask should be able to be independently worked on by a dev.
  • Every subtask should correspond to a PR into a feature branch with its own code review.
  • No subtask should be manually tested by QA on its own.
  • Whenever a subtask can and should be tested and released before other subtasks, it should instead be its own parent ticket.
  • Developers should write (many) unit and integration tests for frontend and backend code in isolation. QA should not manually test frontend or backend code in isolation.
  • QA should write (some) E2E and visual regression tests.
  • Testing a feature should begin once all subtasks have been code reviewed and have gone through UAT. QA should be told which branches to checkout for each repo in order to test the feature as a whole.


When deciding how to ticket and task features, we can ask ourselves the following questions:

  • Does “work A” need to be completed before development on “work B” can get started? If so, they are separate tickets.
  • Can “work A” and “work B” be worked on at the same time by two different developers and both tickets can and should be independently tested and released? If so, they are separate tickets.
  • Can “work A” and “work B” be worked on at the same time by two different developers but contain shared dependencies and require developer coordination? (Lets say “work B” needs commits from “work A”). Do we benefit from having “work A” tested and released before “work B”? If so, they are separate tickets. If not, they should be sub-tasked within the same parent ticket. The developers can then work together to task out the ticket requirements with checklists and issue individually code-reviewed PRs into a feature branch PR. This process prevents QA from having to test two separate PRs. It also prevents QA from finding issues in a “work B” PR that were actually introduced from “work A” (QA should be testing the feature as a whole).



  • “Work A” introduces some backend work that is needed for some “work B” frontend stuff. “Work A” is currently not required for any other tickets or used outside of the scope of “work B”.

The requirements should be broken out within the same parent ticket and the developers should coordinate tasking together and work off a feature branch. If the requirements were in two separate tickets, then QA workload increases and QA can’t thoroughly test that the backend work meets requirements without a UI.

  • An A/B test of a landing page where there are two new variants (“work A” and “work B”), however, each variant shares common new partials.

These requirements should also be broken out within the same parent ticket. This prevents QA from having to test a “work A” variant PR, merge in it, then a few days later test the other “work B [Blocked by #723843264]” variant PR. QA would have to test both variants when they test the second PR anyway since some shared partials were most likely altered in the second PR. Also, since “work A” is not client facing on its own, there is no priority to get it into production first. If the work was in two tickets and one feature PR (a “[Delivered #34543512 #2450912]” situation) then it would have been preferred to have 1 ticket, sub-tasking and a feature branch so that we don’t have to make decisions about when multiple tickets should be delivered in one PR. It is also easier for QA to know that there is always a 1-to-1 relationship between tickets and PRs.

There are many different approaches that scrum teams can take. At the end of the day, the biggest benefit of having some guidelines and consistency in place is that developers have more time to code while reducing the amount of time that the team has to think about the tedious stuff – ticketing, tasking and how we test and deliver features each sprint.