Skip to main content

Team member without task in a sprint

Last post 01:10 pm July 13, 2018 by Steven Langstaff
11 replies
05:24 pm June 24, 2018

One of team member works only with Database related tasks. If in upcoming 2 Sprints there are no tasks relating to Database, how can we deal with this?

04:27 pm June 25, 2018

The entire Development Team is responsible for their sprint forecast.   Therefore, why is such behavior (team members only selecting work based on their preference) encouraged?   What does the team think about this?

05:56 pm June 25, 2018

One of team member works only with Database related tasks. 

If that is the case, where is the teamwork? How can that person be said to be a team member at all?

10:17 am June 26, 2018

In my experience, I have seen developers with one primary skill and some secondary skills. DB experts are usually not skilled in programming (Java) or running any functional test or Java unit testing. Hence utilising DB experts in all sprints becomes a challenge.

02:54 pm June 26, 2018

Kaizar, in working with DB experts, are they open to learning new skills?   Are they willing to help in any way to complete forecast sprint items?

The challenge is with specialized individuals who are only comfortable in their area of specialization and are unwilling to change.   

If Scrum/Agile is anything, it is about change, at the individual, team, and organizational level.

06:10 am June 27, 2018

Different organizations handle it differently.

Some organizations may want to look at individuals as cross-skilled wherein a person has one primary skill and one or more secondary skills.  

Some organizations may want to have a smaller central pool of such skilled individuals wherein they take in work from multiple teams based on their engagement with these teams. 

Some organizations may want to engage external vendors for specialized services like these on T&M basis. 

It is up to the organizational culture and what the individuals are more amenable to in the organizational context. 

09:32 am June 27, 2018

No database is needed for the new features developed by the next two sprints?

What if the new functionality requires a new database field, or does the requirement change?

If the next two sprint can no longer make changes to the database, how agile?

It seems that you cut software requirements in a layered way. And the database structure has been defined beforehand.

Have you ever considered changing the way the user story is written?

05:18 pm June 27, 2018

Here we go with that scrum theory thing again. What the guide says and what real teams do.

My question here is this person 100% committed to your team on every sprint? If not, why do you care? Release them to do their other work. Pull them back in when they are needed in 2 sprints. I have done exactly this. My experience has been with these type of team members DBA, Report writers etc they are a shared service type. They hop on the teams as needed to accomplish a sprint goal. This is communicated throughout the org though and not in a void.

If they are 100% committed that person can be cross trained to say write automated tests. If they are open to it do a little paired programming so they can learn a little more to be cross functional.  Team decision.

I have had this scenario before with report writers, so we added them as needed. There is some resource planning that goes with that, but it works out.

06:08 pm July 11, 2018

When a home is built, plumbers do plumbing, electricians do electrical work, masons do masonry work. Plumbers are not qualified to do electrical work, and masons do not know standards to do plumbing work. Why is there this belief that a DBA can do QA or development, and SHOULD do these types of tasks?

01:18 pm July 12, 2018


Using your analogy, what happens in a construction project if plumbing is next on the list, but there are no plumbers available (perhaps called to another job, or out sick)?   Does the entire construction project stop until there are plumbers available?

I don't believe the suggestion is that those with highly-specialized skills should become a jack-of-all-trades, but that there is a significant risk to skill silos within a team, and that this needs to be mitigated for the overall health of not only the project, but also of the organization.

There is a significant amount of empirical and scientific evidence showing an increase in productivity through swarming, and having everyone on a team contributing in any way they can, as minor as that might be.   This offsets the built-in waste around handoffs and skill silos that reinforce single points of failure.

01:10 pm July 13, 2018

+1 Timothy

A team that does not embrace T-Shaping or Pi-Shaping will never evolve beyond mediocre.

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.