Skip to main content

Scrum Team - allocation of Dev, Test and other Tasks

Last post 08:16 pm June 10, 2024 by Pierre Pienaar
5 replies
10:49 am June 6, 2024

Hello i am a seasoned Project Manager transitioning to be a Scrum Master. I have not managed low level team task allocation so I'm still new 

Scenario/question 1

I have an upcoming Sprint, lets say 50 Story Points of Capacity. 

I have a Mixture of Story points that are Mainly Development for the upcoming Sprint. In that scenario what would the Testers and QA and other colleagues that do in the sprint to keep them occupied? 


Scenario/question 2 

I have an upcoming Sprint, lets say 50 Story Points of Capacity. 

I have a Mixture of Story points that are Development/Test for the upcoming Sprint. Who decides who picks up what story, and how can i be sure they can do the task. If they cant do the work how do i fill up the capacity?. Some organisations Engineers/Devs are focused on one product set so the skills are specific. 


Any guidance Help would be much appreciated please






07:04 pm June 6, 2024

The Developers are collectively accountable for making sure work is Done, tested, and of immediately usable quality. If they are wise, they'll apply good focus and finish work early and often throughout a Sprint. So think of it the other way round. How could any of them ever be unoccupied and idle?

08:16 pm June 6, 2024

As a Scrum Master, you do not manage "team task allocation".

A Scrum Team is a cross-functional, self-organizing, self-managing entity focused on achieving a goal. The Developers are the people on the team who create at least one Increment each Sprint. The Developers are accountable for creating a plan to achieve the Sprint Goal, adapting their plan each day as the Sprint progresses, and carrying out the work needed to get work Done.

Although a Scrum Team is cross-functional, it's also useful to have cross-functional individuals. These are often described as T-shaped, pi-shaped, or comb-shaped people. Although they may have one or a few areas of deep expertise, they are also able to contribute across various types of work.

For Scenario 1, you'd want to keep two things in mind:

  1. First, you want to get work to Done each Sprint. That means designed, developed, integrated, tested, and ready for delivery, if not delivered. When Done, each Product Backlog Item should be valuable for stakeholders. You don't have design work, development work, and test work. A Product Backlog Item describes a change to the product that adds value to stakeholders and you'll likely need several different skills to get it complete.
  2. Second, if a particular person's skills aren't needed on work directly for the Sprint, there are things for them to do. The first thing that comes to mind is refinement of upcoming work. They can help look at the Product Backlog and understand upcoming work, decompose it into smaller (but still valuable chunks), and eliminate dependencies. They can also work on pairing or collaborating with others and developing skills in other areas. 

For Scenario 2, you are going to want to help the Developers to understand their capacity and plan a Sprint Goal and select Product Backlog Items to support that Sprint Goal. Since each Scrum Team is built around a product, most people should have a good understanding of the product or be learning about the product and the stakeholders. The key would be to move from a cross-functional team to a team of cross-functional individuals who can take on a wider variety of tasks.

05:33 pm June 8, 2024

In each of your scenarios, the first thing you need to do is forget about the story points.  You don't have story points, you have work that needs to be done.  

Next, if you have a Sprint where the only work is writing code, then you will not be able to produce a usable increment and the Sprint should be cancelled and a new one planed.

Further, how do you know what is in an upcoming Sprint?  Each Sprint is planned as it happens and not in advance. This is a quote from the Scrum Guides section where the Sprint is explained.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.

The entire Scrum Team is accountable for delivering at least one usable, valuable increment of Product updates each Sprint.  In my 30+ years of software development, I have never seen anything that was not tested before it was considered complete. Perhaps instead of worrying about when these two scenarios occur, it might be better for the Scrum Team if you focused on helping to ensure that the scenarios never occur.

01:47 pm June 10, 2024

A Sprint can be considered a small project. It has a clear objective to achieve - the Sprint Goal. 

The outcome of the Sprint is the valuable, usable Product Increment. Isn't it expected from any other project where software is being produced?

So, what do test engineers do when the software is being developed in the project?

08:16 pm June 10, 2024

What I am going to say was already said, but just to emphasize. The biggest mind switch a project manager moving to a Scrum Master needs to make is that you don't assign tasks. The team decides what to pull into a sprint from the product backlog (during sprint planning). One of the functions of the Scrum Master is to assure the team is empowered as a self-managing team. The Scrum Master should  assure the team as a whole makes the decisions. 

.I like this line from @Danial.

You don't have story points, you have work that needs to be done

As a Scrum Master you don't decide how many story points a team pulls in. The team decides how many backlog items they can pull in, irrespective of the story point count. Over time the story points can average to a specific value, but the team decide what workload they are comfortable with . 

This is a critical mind set change a traditional project manager has to make when moving to a Scrum Master. A Scrum Master is still a leader, but leading by helping the team to make decisions, and stop one individual to dominate 

You will need to trust the team that all will be done, but the team is not going to learn unless you allow them to think. Initially mistakes will happen, but persist and let the team learn from their mistakes.

(On your scenarios especially 1,, let the team break the tasks into smaller items, with each item having a Dev and QA component. Every sprint needs to produce working code that is also tested )

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.