Scrum Cards (User Story and Task)

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.

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.

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.

Hello,

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.