Skip to main content

Scrum Cards (User Story and Task)

Last post 08:28 am April 1, 2013 by David Malinowicz
4 replies
10:02 am March 26, 2013

Hello Scrum Community,

Can someone give me an idea of how many of the following items typically exist on a medium and large organization scrum board during a sprint. I realize that these numbers will vary, but I was hoping to get an idea of the minimum and maximum number of the following card types.

- Story Cards
- Task Cards

Additionally, which team members (dev, design, content, ux) are there typically task cards for? Am I missing any?

Thanks for your help!

11:16 am March 26, 2013

Story Cards
The only guidance I believe you can or should accept from outside your own team is "more than 1 story card". The size of a card does not translate in any way between teams.

The reason I can am willing to give the guidance of "more than 1" is simply the risk of nothing will be Done as more is learned about the Product backlog item during the Sprint. In all cases, Done means shippable should the Product Owner believe enough value is accumulated to release to customers.

Task Cards
It sounds like you're using task cards as your plan to accomplish the sprint's goal(s). In this case, I imagine you'll want these for everything necessary for your Story Cards/Product Backlog Items to be fully Done. Again, Done means shippable should the Product Owner believe enough value has been accumulated to release to customers.

12:33 pm March 26, 2013

Hi Josh

The number of cards in the Sprint backlog can't be generalised at all, because it's up to the team how much they are prepared to commit to. What can be said is that it is usually best to have lots of cards with low estimates in the Sprint backlog, because that is likely to improve velocity. A small number of high-estimate cards is more likely to sit in progress for a while, increasing the risk of value not being delivered in a timely manner.

It is a bit easier to generalise about the number of cards that would be in progress. Ideally only one story card will be in progress at any one time (though it could have multiple task cards). This is known as single piece flow and it is - theoretically - the most efficient way of working. It minimises the amount of work you have in hand at any one time while potentially increasing velocity. In practice, most teams have to back away from single piece flow because it isn't practical to have everyone swarming on the same story...even with separate tasks they could be falling over each other. What can be said is that the number of cards in progress should not exceed the number of team members, because each member should not be trying to work on more than one thing at a time. Scrum recommends a team size of between three and seven members, so you can take the arithmetic from there. Just remember that you want the number (the Work In Progress or WIP limit) to be as low as you can reasonably get it.

Scrum does not differentiate between dev, design, content, and UX people. They are all simply team members, and they are expected to be sufficiently cross-trained so as to be able to action the next item from their Sprint backlog, regardless of what the requirement is for.

09:25 pm March 27, 2013

Hi -

I feel story card is more like a use case while task card is the task/activities. As per scrum norm - task card should not be more than 1 man-day worth of effort. We should break story into so many task cards that can be achieved in a single day.

Based on the story card/use case, you can not have any min and/or max # within a sprint. It could be one WIP story card to 1 story point or more in one sprint while definitely there would be (# team member * no of ideal days) of task cards (again ideally).

On the task cards responsible for - it should be the team, cross-skilled, cross-functional team members who should own it.

08:28 am April 1, 2013


Depending on your internal workflow, we find advantages in using both - in particular Story-type cards. During our sprint planning sessions, we create these user workflows or stories to guide our QA resources during testing - in particular front end user testing.

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

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

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