Who can add “tasks” in Scrum/Kanban?

Question

I am using Kanban for the process of etablishing a company. It may be kind of wrong since I am both the product owner and the development team. But I think it works, the user stories turns out good. But as a product owner (owner of the company) I need to do different stuff that does not fit user story format. Is the "task" concept for new issues only for the development team to create? Or can I as a product owner also add tasks that I as a product owner can do?

How do I do this right? Must I create another project, board, ...?

Answer 1

When doing Kanban in my previous company, anyone could create a task or story or epic on our board. However only the PO could prioritize it.

In my current Scrum company only the PO creates Epics, and Features, and usually creates the User Stories. The Dev team create tasks and some "technical" User Stories.

Is the "task" concept for new issues only for the development team to create? Or can I as a product owner also add tasks that I as a product owner can do?

In either situation it was always possible for a product owner to create tasks for them to do themselves. you might find in your Kanban board that the PO tasks don't follow the same process as the Dev tasks. i.e. PO tasks may have a path of

To do ___ In Progress ___ Reviewed ___ Done

where as the Dev tasks may be more like

Backlog ___ Review ___ Develop ___ Unit Test ___ System Test ___ Install to Prod ___ Closed

If this is your case a 2nd board to map out the 2nd process is the way to go. if the process is the same then the same board is fine.

Different coloured cards can be used as well to help visualise the tasks that are for the different roles if you like.

Regards

Answer 2

Great question. The terms Backlog Item (PBI), User Story, and Task are often used in different ways and that can be confusing.

The simple answer to your question is that on a Kanban board (especially outside of Scrum) you usually have one level of item that may be user stories, tasks, tickets, requests, or whatever your team needs. So, if you want to generalize these things to "Tasks" instead of trying to use user stories, there is nothing wrong with that. For that matter, you can even use a mix of different types of items - they're just all on the same level.

With the simple answer out of the way, here's a little more complexity:

In scrum we commonly see two levels on the board: Backlog items and tasks. The reason is that it lets us distinguish between the value-add item (the backlog item - often a user story) and the discrete small thing to be done which is just a step in delivering the larger item. This is because, in scrum, we want to use the board for the team to organize their work (tasks) but also keep an eye on how the team is progressing toward adding valuable functionality to the product and achieving the sprint goal (PBI).

In a purely Kanban board, I'm just concerned about the flow of work, so there usually aren't multiple levels of tasks. In most cases, everything in a Kanban board is value-adding and the steps to deliver it come out in the columns of the board.

Answer 3

Writing requirements: User stories represent exceptionally high level "desirements" written from the end users point of view to emphasize the business value as opposed to technical details. Stories get refined as the next sprint planning meeting gets closer. Eventually, the dev-team decomposes the stories by adding granular tasks. Keep in mind, there are other formats such as user journeys, use cases and so on. User stories don't work well non-functional requirements, for example. So why restrict yourself and your team with user stories? Having said that, majority of your backlog items should be written in story format unless you are working on a product that does not interact much with users.

Who does what: The product owner should write the high level user stories. The dev-team would then, during backlog refinement sessions and sprint planning, add the tasks to required to complete the user story. This is the natural division of work but not a strict rule. Given you are also a developer, there is nothing stopping you from writing tasks. Similarly,

A note on Kanban and Scrum: Regardless of whether you use an online tool or a board with sticky notes, it makes a lot of sense to differentiate different types of tasks. If your tool doesn't support types of tasks or adding sub-tasks, then use labelling or color coding. Even the simplest/free tools such as Trello provide this feature. So your stories would be Yellow, and all its sub-tasks orange. Other colors represent other things. This is easily do-able using sticky notes too, which come in different shapes and colors :).

Answer 4

This is something that the team can decide together. Figure out the different types of work (new story, bug resolution, ops changes, etc.) and agree on how new pieces of work in each category is introduced into the stream and by whom.

I suspect you will find the most value in keeping all the work for a given product on the same board. Separating types of work will leave you with biased sub-views; you want to visualize the whole picture.