I would use Story points rather than T-shirt estimates - because you can easlily add up the story points you complete each week - which you cant do easily with T-shirt estimates.
The problem with T-shirt estimates is that in one sprint you might complete
- Four stories - S, S, S, S
- Next sprint you complete two stories but of different sizes - M, L
Then when you are planning your next sprint you can't really tell how much you willl complete - as you can't easily add 4x S and M+L and compare with what you have in your backlog. Story points help here because you can add up the numbers - and you have a single number which is your velocity. (Check out the section - How is your velocity calculated - in this article: https://smartguess.is/blog/what-is-agile-velocity
To answer your question - how to know your team capacity - then your teams velocity is exactly what you are looking for. It answers how much work you complete in a given sprint / week / two weeks or whatever timeframe you use.
The article above explains velocity and how to use it to answer related questions such as:
- When you can deliver a feature?
- What can you deliver before the end of next week, month, quarter?
Notice the blog post above is a part of a series that goes step by step and explains the key concepts and how to set everything up in jira to start using Story Points or T-Shirt estimates.
Regarding to "assign each task to a size according to how long it takes a senior to finish it." This is not a recommended practice. The purpose of relative estimation is to move away from asking:
- 'how long will it take 'me' to implement this story?' - people with different experiences will take less / more time depending on their skills and experice level.
So instead with relative estimates the team asks:
- Is this story smaller, same size or bigger than other X point story I have in the backlog?
Here is a article that talks about this: https://smartguess.is/blog/why-storypoints-and-not-hours/
Hope it helps!
Björn Brynjar
Ps Was teaching these methods in the University for years - so let me know if you have any other related questions 🤓
Hi @Sara Yasser ,
I find Scrum helps assess team capacity more accurately and enables more predictable planning, since teams plan based on their velocity and avoid overcommitting beyond it. Would you be open to trying Scrum?
In Kanban, you can achieve something similar by defining the team’s throughput (the number of stories completed within a given cycle). To make this effective, it’s important that stories are relatively comparable in size, or, if not, to at least classify them as L, M, or S. I don’t believe relying solely on estimates from senior team members is accurate, since junior members may need more time. Their contributions and perspectives should also be factored in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Sara,
In the report you build it is important the time basis (tipically a week, 2-week, month).
To set the sizes, I would recommend the comparison method comparing work items with a "well-known standard S-size task" without comparing to the time a senior needs to complete the task. Your team is not composed by only seniors, it's better to adjust to a medium profile.
Regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Sara,
Using T-shirt sizes (S/M/L) to estimate tasks is a smart way to measure your team’s capacity in Kanban. It helps you understand how much work your team can handle by sizing tasks based on how long they typically take.
Try sizing tasks together as a team, then track how many sizes you complete each week to get a sense of your capacity. Adjust as you learn over time. This keeps planning simple and flexible.
Hope this helps! Let me know if you want more tips.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.