Skip to main content

How do we manage missing a missing skill ?

Last post 08:59 pm January 7, 2016 by Bastien Wink
4 replies
02:39 pm January 6, 2016

I'm a Scrummaster working with 3 developers having the following profiles
- Tom is good with iPhone and graphic design
- Jack is good with servers and technical design
- John is good with Android

My definition of a Done story contains "Released on both iPhone and Android".

For the following 2 sprints, my Android guy is off.

So all my stories will be "half-done", released only for iPhone. How should I manage my backlog and sprints then ?
And I'm struggling to keep it Scrum-compliant (or at least managed a nice way)

Even when the guy will be back, the Android version will be 2 sprints behind the iPhone version for a moment.

Splitting my Stories into 3 items of the backlog (Server, iPhone, Android) looks bad. What else is possible ?

Notes :
- I know there shouldn't be defined roles in Scrum, but only one have the Android skill.
- This does not happen with larger team, but our budget is limited to 3 devs.


Thanks for your help.


03:15 pm January 6, 2016

If the team can't meet the Definition of Done for the work being asked of them, then they should not agree to start the sprint. If they don't have the skills and/or the people then they have a duty not to commence. No-one can force that work onto a team.

If the Product Owner would find value in an iPhone-only release, and can manage that value without Android dependencies, then a different DoD may be negotiated for what is essentially a different component product. However a Development Team with only 2 members is too small for Scrum and so they may still reasonably refuse to commence sprinting.


06:09 am January 7, 2016



- I know there shouldn't be defined roles in Scrum, but only one have the Android skill.



Of course there are. What you mean is: There are no titles for Development Team members other than Developer.
And the great thing about experience is: Now you know why.
Titles like "Android developer" encourage members to work on separate things rather than collaborate.
Collaboration causes skills to spread through the team which solves your problem of scarce skills.
For the moment I agree with Ian: The team cannot commit to deliver a done increment, if "done" includes things the team lacks the necessary skills for. In order to deliver the highest possible value while keeping transparency high, I would change the DoD accordingly, make it transparent to the organization that it has a dysfunction here and work with the team on this problem of scarce skills.
This means: Ask the team for ideas how to solve them.
When I have done this, they often had great ideas like pair programming, trainings etc.


10:47 am January 7, 2016

Agree with Ian and Ludwig.

You've identified an impediment that needs to be made visible within the organization. This is a classic example of the limitations around specialization - use it!

I also see part of the issue around the definition of product (combining IPhone and Android), but based on your current set-up and limitations, it may be a constraint that you just need to deal with short-term.

You state that your DoD has "Released on both iPhone and Android". Who crafted the team's DoD? It just seems that this situation should have been foreseen, and the team should have been thinking of ways to mitigate it already.

It seems too that there could be possible stories that may not require releasing on both platforms (either IPhone or Andriod-specific functionality), so I'm uncertain why the DoD criteria is so restrictive.

And finally, I don't see why splitting your stories by destination platform (server, IPhone, Android) looks bad. What better way to promote much-needed cross-training and pair-programming than having your 3 developers working together on an story that targets only one platform?


08:59 pm January 7, 2016

That really helps, thanks Timothy, Ian and Ludwig. Glad you spent time writting for us.

So that's my first week with this team, the DoD, member's specialisation and lack of earlier forecast on the situation have been given to me as it is. I intend to fix that as good as I can. No one in the company would dare refusing to start the work, glad enough we are getting more Agile.

The solution we implemented today is to split the stories by destination platform, and change part of the DoD to be "Released on the platform mentionned in the story".
That make my backlog twice bigger, but it got accepted by PO.

Hopefully that will introduce cross-training, but it also can split my team as Android and iOs does not "have" to work on the same story anymore to reach the DoD.

I'm looking forward for my team to be more cross-trained, it might take a while considering my Android guy never touched a Mac ;)


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.