Published in

eosdesignsystem

# How We Adapted Our Scrum Cards Deck And Made Scrum More Efficient

We are a team of creative people, most of us with some background in Design, and some with only it. When I introduced Scrum to the team, again, a team of creative ones, it was quite confusing for some members of the Scrum team to estimate with numbers (Fibonacci) those cards that involve some development or tasks they don’t understand how to work with. That is fine, it is the nature of every Scrum team: to be cross-functional, learn from each other, which that leads to these type of situations in which some members will just skip providing some estimation.

In our case the members skipping the estimation sometimes were more than 60% the Scrum team, and … well, that made things a bit complicated to go on with our plannings.

I, by then the Scrum Master of the team, needed to find a solution: the people in the other 40% felt as if their tasks were less important when people were just “skipping” the chance to estimate and give value to their cards, while in the other hand, the people in the 60% skipping estimations were feeling “dumb”. Neither pleasant feelings.

# Numbers are too specific and hard to agree upon

In my journey investigating and trying to improve the process I came across all the different estimation scales for planning poker:
- Fibonacci ( 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ?, Pass )
- Modified Fibonacci ( 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Pass )
- T-shirt sizes ( xxs, xs, s, m, l, xl, xxl, ?, Pass )
- Powers of 2 ( 0, 1, 2, 4, 8, 16, 32, 64, ?, Pass )

As said in the title, numbers were not working for us. They are very easily associated to hours or days of work, and as every scrum person knows, we estimate effort and not hours/days to be spent on a task, why? let’s make a simple example:

if we estimate that a card with title “Implement authentication with Passport.js and Github strategy in the website” requires 2 working days to be accomplished, well the assumption is wrong just to begin with, because:

• Scrum teams are cross-functionals, so the member A who is a very skilled JS developer might estimate the card with 2 working days, because he/she has already done this in the bast, while member B who is a mid level developer and has never used Passport.js before, will require some time just familiarising himself/herself with the module first.
• S* happens all the time. Work stations break, people get sick, bugs happen and arise in the priority list, etc. They will get in the way of every development team, and if you estimate that next sprint a card will be done in 2 days after moving it to doing, well, you are a very positive person.
• Reviews also happen, and they can be painful some times when the reviewer is very picky or when there is some discussion involved in the process, and disagreements can also happen, extending the time of that open Pull request.

Many factors, many reasons not to estimate days or hours of work, but rather effort.

So that was clear to me, numbers are not working. But why not T-shirt sizes?
Well, that is another measuring technique that in many people’s experiences fails: Have you tried going to the store and buying a T-shirt for a colleague? it takes time to figure out his/her t-shirt size, and most of us end up texting a relative that can give us the right size, otherwise it could be too big or too small.

I’m not saying it wouldn’t work for us, maybe it would if we simplified it to just Small, Medium, and Large. And yes, in the end that was what I did, but I added some customisation to it to make it a bit more illustrative. Let me show you the final design of our deck first:

Primarily, there are only 3 cards that add an actual estimation value:
-Light (green)
-Medium (yellow)
-Heavy (red)

The light card is represented with a feather icon and also the green colour. The medium card is represented with bowling pins and the yellow colour. Finally, the heavy card is represented with a bowling ball and the red colour.

Colours are universal in User Interfaces, and mostly if they are the traffic light colours:

• Green is: good, easy, good to go, etc.
• Yellow is: warning, mid difficulty, cross with caution, etc.
• Red is: error, problems, hard difficulty, do not cross, etc.

Automatically, those 3 colours trigger something in our brains the moment we see them, plus, they are also associated to weights.

# Put the cards into action

Before actually deciding we would use these set of cards in our next planning, I wanted to make an experiment with the team.

Here is the presentation I made for this purpose: http://slides.com/cynthiasanchez/deck

I presented the following images:

Then I asked the team to guess the weights of those 3 men using numbers. As you would guess, for the first person everyone was around 200 and 300 Kg, for the second one between 60 and 100, and for the last one between 40 and 70. Even though the estimations were somehow close, there is still a big gap in between one and the other, and it would require more than 1 estimation rounds to agree on 1 number for the 3 of them, and here is were this gets interesting: Time!… but wait, let me get to the second round before giving the conclusion, although, I’m guessing you already got the point, but I want to make sure everyone understand it.

So then the second round was different and we used the new cards deck with: light, medium, and heavy. It was not a surprise that everyone agreed in first round saying that the first person is Heavy, the second one is Medium, and the third one is Light. Of course, if we put a photo of a puppy in the estimation, then possibly the result would have changed having now 4 candidates instead of 3. It would have required maybe 2 rounds to agree on the last 2 cards, but nowhere as many rounds as guessing with numbers.

# Time is money, and it is a lot more!

The point is that agreeing upon 3 different measuring units as broad as Heavy, Medium, and Light, saves time!

Time isn’t just money paid to managers to produce reports. Time is also:

• Creative and productive momentums wasted in meetings: it takes even more time to recover from boring meetings than from a 15–30 minutes coffee break, so make them as short as possible.
• Every person has a different time when their Proactive Attention triggers: the normal human being has ~3 hours a day of proactive attention, this means, it only happens around 3 times a day that a person has the initiative to do work on something him/herself decided to do. The rest of the time they will be on Active attention, which is the attention level required to just continue working, continue with the flow, or Passive attention, when we can’t do much thinking but rather some low-level tasks like email processing and etc. (find a short presentation about this topic here: http://prezi.com/nqouman-ym4h/?utm_campaign=share&utm_medium=copy&rc=ex0share)
The thing is, you should be careful you are not wasting one or two hours meeting of the Proactive time of your people, wasting chances for them be proactive and create interesting stuff.
• And time is also time the team could have spent finishing that card that has been in review for some days, that bug that is very frustrating and we want to close as soon as possible, etc.

And many other things that, the more time we spend on estimations and Scrum meetings in general, the less accurate the estimations will become because people will try to just agree to finish the meeting as soon as possible to be able to be free again.

Remember: only the PO and Scrum Master are 100% into the scrum meetings, the rest of the team just wants to get back to their computers ASAP!

# But, what are the other 4 cards in your deck?

Okay, you may have noticed that the image of our cards deck contains 4 more cards. They are very easy to explain, so let’s go to the point:

First off, so you understand, we never allow cards into the sprint that can not make it within 1 sprint. This is the general Scrum rule, but I know of some teams breaking this rule, and that is fine, I don’t believe scrum-by-the-book fits with every team, so it is good to customise it a bit.

The Pair card

It is made to improve collaboration within the team. It means that when a card looks to be a good candidate for a pair-programming, or pair-code-designing, or pair-designing task… a pair activity in the end, we combine our estimation card with the Pair card, e.g.: Heave + Pair. Then, this card will need to be worked in pair.

The Break it card

When a card is just too big for the sprint, bigger than a heavy, the members of the scrum team will request to break the card into smaller tasks that can be delivered within 1 sprint.

The ??? card

It can be used in 2 ways:
1- I have no idea of how to estimate this card, so I will pass the estimation.
2- I didn’t understand what needs to be done, so I pass the estimation for now and request that the PO describes the task again.

The Time out card

When the meeting gets too long, or the discussions over one card for estimation was too long, people’s brain need a rest. I encourage everyone to use this card whenever they need it so then the next estimation isn’t at risk. The time out shouldn’t be more than 5 or 10 minutes, otherwise you will end up wasting time again. The how often to allow it as a Scrum Master, is up to you, but I would recommend allowing at least 2 breaks every 1 hour spent in the meeting.

The poker symbol is only in two cards, why?

The Pair and the Time Out cards have a special icon.

This icon means that those cards should be used together with any of the other cards.
You cant say a card is for Pairing without giving a weight or at least a ??? or break it card, just as well as you can’t request a time out in the middle of an estimation round without finishing the estimation, for example, let’s say that someone is already tired and wants to take a break, this person needs to give an estimation together with the timeout card, we will finish the estimation rounds and then have a 5 or 10 minutes break. Giving just the time out card would mean having a break and after 10 minutes try to get back to the topic, this will waste more time and we would be breaking the momentum in the discussion.

# I want to give a try to your Cards Deck

Or the simple .JGPs from here:

And again, if you need my presentations, they are here:

Any feedback would be really good! I would love to know how it worked for your team. My twitter is account is @cyntss.

Thanks for reading, and share if you liked it :)

--

--

--

## More from eosdesignsystem

Articles created by EOS team

## Cynthia Sanchez

Product Owner and technical lead at SUSE. A passionate entrepreneur and creative looking for ways to improve individuals life.