Skip to main content

Estimating ideas for non multi-skilled team

Last post 03:31 pm January 19, 2017 by Ian Mitchell
1 reply
08:17 am January 19, 2017

Hi,

I have a new scrum team with a BA, a tester, a UX specialist and 3 developers. Each developer can cover only his specific area of expertise, ie Web, SAP and salesforce.

I've been a scrum master for many years and I'm experienced with story point estimation using several techniques. However, when there is absolutely no common ground between any of the team members I'm struggling to come up with a method where we can give meaningful story point estimations from the start.

I have another team with the same siloed skillsets but they have been together for a while so we have the advantage of collective experience and many past stories for reference in order to give the story points some context and meaning.

Ideally I'd put together a team of multi-skilled individuals, and this is something we're working towards, but it's not our current situation. And over time, they will get the experience and completed reference stories that the other team have, but it would be good to have meaningful story points from the start.

Does anybody have any ideas or methods I can try?

Cheers,
Tim


03:31 pm January 19, 2017

Try taking story points out of the equation to begin with and use T shirt sizing. All you need are six scraps of paper and a set of index cards with the requirements (e.g. user stories) written on them. Normally these will be the same index cards that go on the Scrum board.

Write one of the following sizes on each of the scraps of paper: Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL), and Extra Extra Large (XXL)

Arrange the sizes in a horizontal line on a table, ordered from XS on the left to XXL on the right.
Put the pile of index cards on the table in front of the sizing line.

The team then collaborate to organise the requirements on the cards under the headings XS to XXL. They can ask the Product Owner to clarify any questions that they may have while doing so.

Once the cards have all been sorted, story points can be allocated to each of them by mapping each T-Shirt size to a value. This allows metrics to be gathered about the flow of work, and used to populate a velocity or burndown chart.

XS 1
S 2
M 3
L 5
XL 8
XXL 13

An advantage of the team sort is that it is quick and easy to do. The complete set of requirements is estimated in one sweep. Also, it is a fairly direct way of achieving relative sizing. There is no temptation to correlate points to hours. The disadvantage is that it is potentially undemocratic, in that assertive team members can dominate meeker ones with their opinions.

There is a variant of the team sort which encourages more egalitarian behavior. Each team member takes it in turns to move one card by one position. They also have the option to pass, i.e. to not move a card. Eventually a consensus should be reached and no more cards will be moved. However this is a more time consuming method and deadlocks can occur. These deadlocks can be difficult to spot if multiple card shifts are caught in the cycle.


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.