Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I noticed that Scrum boards have the following columns, the one I am asking about is the 1st column "Stories".
Before a Sprint begins, you take stories from the Product Backlog that you will work on and complete during the Sprint.
When exactly do you break the tasks out for each story?
Does everyone break stories out into tasks? Is this specific to Scrum and not say kanban?
This is just one way to lay out a board in Scrum, but it is a common way.
In Scrum, they do not say that you have to use tasks. However, Part 2 of Sprint Planning is where the team comes up with the plan on how they will deliver on the sprint backlog, so I would expect the tasks to emerge there.
Does everyone break stories out into tasks?
If you mean "Do all teams break stories into tasks?" the answer is no. Some teams do not use tasks and that is fine. When I coach teams that don't, I do keep a close eye on how well they are able to plan to deliver stories without them. Some teams do this fine, some don't.
If you mean "Are all dev team members involved in task breakdown" the answer is yes. This promotes shared code ownership.
Is this specific to scrum and not say kanban?
It is not specific to Scrum. I see XP teams do this as well as other non-scrum frameworks. That said, I would not expect to see this in Kanban. Kanban has a lot of focus on the flow of the backlog item (story in this picture) through the process. I'm sure there is some team out there effectively using tasks in Kanban, but when I've seen teams try it they usually find it is more confusing.
I've setup quite a few scrum teams using kanban boards. We typically use a column for stories that aren't started. Then a column for in progress, in test, and done.
Every story should have a description about "what" is being requested with a clear definition of done listed on the card. Typically tasks are details about "how" the work will be done. I've had best luck with leaving the tasking up to the team. Many teams write (non-value adding) tasks like "do the work" or "test the feature". If your definition of done is a checklist of things to be done for acceptance of the story, then you can eliminate the extra management of separate cards for tasks.
Regardless of how the effort is organized, approached, and executed within the framework, Scrum helps to expose the opportunities for improvement. If/How/When a team decides to use tasks, user stories, and other techniques is at the core of self-organization which is a Scrum requirement.
Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
Take some time to read and understand The Scrum Guide and its history. There are many sources out there providing information as "Scrum" that present common practices as rule; some information is entirely inaccurate. As a framework, Scrum does not prescribe many details; it provides a structure within and upon teams can execute complex work using their choice of tools and processes.
User Stories are a concept from eXtreme Programming. They have lost their original intent and often become traditional requirements. Product Backlog items can be represented in any format with the "As a, I need, So that" User Story or the Job Story formats being common.
The concept and use of a "Scrum Board" is common, yet not a requirement. It comes from kanban in manufacturing. A kanban board is used for tracking progress through many steps in a process in order to locate and address inefficiencies. Continuous Flow Diagrams (CFD) are a common tool to discover such inefficiencies. Within the Scrum framework a Product Backlog item is either 'Done' or not. Ideally only three kanban columns are needed and used: To Do, In Progress, Done. Additional columns may indicate processes that are still based in separate sub-teams1 or not using best practice techniques such as test-first including unit and or acceptance test driven development. CFDs can help identify such opportunities for improvement.
Tasks are another common practice from traditional project management2 where work items were often still somewhat relatively large efforts. The details, tasks, were left to those executing those specific activities within the line item. Creating Product Backlog items that are thin, vertical slices of functionality is often preferred to tasks. Tasks can once again be an indicator of sub-teams.1
1Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis;
2Project Management being based upon and often still rooted in manufacturing. Thus Scrum's product focus. (Yes, Scrum was based on lessons from Toyata so it's not completely divorced from manufacturing.)
Join me in chat if you are interested in learning more.
