T-shirt sizes, planning poker, and capacity/velocity
Extra things you can do around sizing tasks
One way to check that your tasks are a reasonable amount of work and have been broken down to the right level is to size them. When you’re saying whether a task is big or small, you’re really taking your best guess at how long it will take to do. Now, humans are notoriously bad at successfully predicting this. Even when it’s a task similar to one we’ve done before, we often forget or gloss over some of the steps involved. So, sizing is not necessarily super useful as a measure of how many tasks you’ll be able to do, but it can still serve a very useful psychological purpose.
T-shirt sizing – an alternative to story points
Usually, we use story points to size our tasks. However, if you would prefer an alternative method, then I would try T-shirt sizing.
’T-shirt sizing’ is exactly what you might imagine – extra-small to extra-large, and you can add more X’s if you’re feeling keen. The scale you use is up to you, but for tasks I would suggest something like:
- XS – Minutes
- S – Hours
- M – A whole day
- L – Several days
- XL – A week or more
Anything bigger than an L is probably too big for a single task, and needs to be broken down further.
You can also use T-shirt sizes on a larger scale when considering whole goals or projects. In that case, your scale might look something like this:
- XS – A few days
- S – A week or more
- M – A month or more
- L – Up to three months
- XL – Up to a year or more
You can adapt the scale to work however you like, for instance on a much smaller time-scale, e.g. starting with XS being five minutes, S being up to half an hour, etc.
Planning poker to vote on story points
In my team at work, we have a weekly ‘refining the backlog’ meeting where we go through tasks which have been gathered and size them using story points. To do this we use a game called ‘planning poker’, which is simply a real or digital pack of cards for each of the Fibonacci-style numbers typically involved with story points (0, 1, 2, 3, 5, 8, 13, 20), as well as a question mark (‘don’t know’) and a cup symbol (‘I’m exhausted, time for a tea break’)). After we’ve discussed a task and what might be involved, we all vote by holding up a card with the points we think it’s worth. If there’s disagreement, then those with the lowest number and the highest number make their case, and then we all vote again. If there’s still disagreement, we err on the side of caution and take the higher number. Nowadays, we use a website to do this.
However, at home we’ve found that this whole voting rigmarole is far too slow and adds an unnecessary layer of bureaucracy. Since there’s only two of us, we have got a good shared sense of how much a task should be worth, and so whoever is writing down the task immediately adds a story point number to it too.
Story points can be used to give an overall picture of how much your team is likely to be able to do. You do this by adding up how many story points you finished in the previous sprint. This is your ‘velocity.’
Based on the velocity (essentially, your pace of doing story points), you can in theory estimate how many story points you might do next sprint (which is the team’s ‘capacity’), and therefore limit the number of tasks you commit to during the sprint accordingly. However, velocity is just one piece of information. Your estimated capacity can’t take into account whether you’re working on things which are more difficult than in the past, so it shouldn’t be given too much weight as a way to measure expectations or as a form of progress. Velocity and capacity can be useful for a team who is reflecting on ways to improve. They should not be used outside the team to judge performance.
Now, it’s completely up to you whether you want to try and apply this or not. Francis and I have never really managed to. For a start, there’s an argument to be made that since humans are bad at estimating anyway, most of these numbers end up as meaningless. Secondly, it’s quite tedious to calculate these numbers (especially given you’re using a physical board) and anything that makes you more likely to avoid engaging with Scrum is a bad idea. If you are curious though, it might help you be more realistic about how many tasks/story points you can achieve in a certain time frame.