Taiga-front: issue vs user story vs task on boards

[emmanuelbuah]

I'm confused why we cant add a task or issue to the boards (kanban or scrum) without a user story? What's the reasoning behind it? Why the restriction? Boards are suppose to provide the big picture of development todo's which might include tasks, issues or user stories. You can certainly require user stories for every issue or task (include dev ops stuff) but that seems like an overkill. Taig have done a lot of things right. I hope you will consider making this change to give users the freedom to use it the best way possible rather than restrict it.

[superalex]

Hello!,

We share the standard scrum point of view about what user story and task means. A user story, is a way to define a software feature from an end-user perspective. For example, a user story may look like "As a user, I want to be able to update my profile with age, present occupation and social interests, so that people visiting my profile page get an idea of my interests". A task, on the other hand, is typically something like code this, design that, create test data for such-and-such, automate that, and so on. These tend to be things done by one person. When creating a backlog or doing estimations you should be thinking at user story level, not in tasks, that's the reason why backlog work with user stories.

The usual scrum workflow divides the user stories in tasks when you create a sprint and you move them there, that's the reason why the visualization of tasks only makes sense when you have selected a sprint.

Backlog -> works with user stories
Sprint -> work with tasks from the user stories associated to that sprint
Issues -> we use to cover any other items that can have different workflows, the most common should be bugs/defects

Conceptually it makes sense not to mix these three different items under the same areas. Another thing to consider is that in taiga user stories, tasks and issues have completely independant and customizable workflows with different status, so they can't be grouped by it. What Taiga supports is the "promote to user story" feature for issues, we found that commonly there are issues that really are user stories but the team needs to keep full traceability about them.

We have an article in our blog speaking about user stories, it could be usefull -> https://blog.taiga.io/user-stories-demystified.html .
There are also a lot of articles about the differences between user stories, tasks, epics, features...(for example this one https://www.mountaingoatsoftware.com/blog/the-difference-between-a-story-and-a-task).
I would also recommend the reading of https://en.wikipedia.org/wiki/Scrum_(software_development)#Artifacts (the different artifacts used on scrum), it also includes a clear explanation about how backlog and sprint at user story and task level.

Regards! ;)

[emmanuelbuah]

@superalex Thanks for the response and do understand the differences between story, tasks and issue. What i had hoped to communicate is that all the agile processes (scrum, kanban, xp etc) are different levels of agile with different restrictions. Even the wikipedia link you sent me even states clearly:

There is a common misunderstanding that only user stories are allowed in a product backlog. By contrast, scrum is neutral on requirement techniques. As the Scrum Primer[19] states, Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain "user stories"; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.

These tools are suppose to be flexible so you can make them work for your team not that other way around.

To further illustrate why other items are needed on the board other than user story, Here is an example. Assuming we want to implement a signup feature. We will create a user story like "As a user, I want to be able to sign up with my email and password so I can log in to use the application". We can create tasks off this user story to be completed and released. At this point, we are all good.

Let assume an issue is discovered in the sign up process after deployment so a bug is filed. The bug reads "Can't sign up with email [email protected]. Receive an invalid email error on sign up". Ok, so now we have this bug. Question is, with your current restriction, how do we get this bug onto the scrum or kanban board?
Per your current design, we will promote it to the user story but the user story has already been completed. A user story for the current bug will read the same as the user story that was completed. In essence, user stories aren't good enough to express bug behaviors. The nature of bugs is to specify an unexpected and undesired odd behavior while the nature of a user story is to specify what they user can do. They are not one and they same and cannot be substituted.

I'm making this comment because I think you've got a lot of things right but is just overly restrictive. The definition even in wikipedia clearly states that. I hope you can take my feedback into consideration.

[emmanuelbuah]

I was really excited to use taiga but this is a big risk for my team. I will continue to play around with it but this restriction is a big risk for my team to continue to ship our software effortless. We don't want another tool to fight with.

[superalex]

Thank you very much for the feedback @emmanuelbuah but I'm afraid we don't plan changing this core part of Taiga in the short/medium term but we will consider all this comments in the future.

As a workaround if you need to use bugs as user stories you could just create them as user stories and add some kind of tagging over them, this way you could always filter them easily in your backlog and move them to sprints when needed.

Regards! ;)

[tknecht]

I totally agree with @emmanuelbuah This is one of the topics where our team is blocking on.

An elegant way would be to add an option to add Issues to an User Story as if they would be a Task. This would immediately solve the problem and it has quit a few other benefits.

Thanks

[AndersMadsen]

The ability to view a taskboard for a single user story is something I'm missing, a lot of teams use scrum, kanban and/or xp as agile methods, or take some of each to find something that works for them.

For a method to be agile it needs to be flexible and should be able to suit the needs of the team, therefore it makes no sense to lock down a feature in Taiga and require teams to work a specific way, it will benefit the user more if they were able to customize it, so they are able to have issues as a task board, sprints as a task board, user story as a task board, backlog as a taskboard and so on.

Since you already Give the user the option to chose a kanban or scrum template you can set the settings for that project like this;

_when talking of tasks, it is defined as a task on a user story_

For the kanban template: Activate User Story taskboard (old method of showing tasks on a board)
For the Scrum template: Activate Sprint Taskboard (current method of showing tasks on a board)

A good tool does not dictate it's user, a good tool can adapt to the need of the user.

[fabue]

+1

[SenlaDev47]

+1

[MichaelHierweck]

Some questions related to tasks when working with the Kanban template:

• Can tasks (not stories) be shown on a board when using the Kanban template? How?
• How can the user story details screen (to manage tasks) be accessed from the Kanban user story board?

[bameda]

Can tasks (not stories) be shown on a board when using the Kanban template? How?

No, kanban only works with stories, you only can view tasks in the story detail page or if you enable scrum in the sprint taskboard panel.

How can the user story details screen (to manage tasks) be accessed from the Kanban user story board?

Clicking in the name of the story in the card.

[Neutrino-Sunset]

"The usual scrum workflow divides the user stories in tasks when you create a sprint and you move them there, that's the reason why the visualization of tasks only makes sense when you have selected a sprint."

Scrum embraces pragmatism. For every team that uses cannonical Scrum there are a dozen others that have tailored it to meet their needs. One of the first things that goes out of the window is often the idea that you break stories into tasks during half a day of sprint planning. In reality systems development is far too complex for that to be remotely realistic so teams learn to start the job of analysing stories and defining tasks well in advance. That job may even form a task in a preliminary sprint. Taiga supports this and that is good to see.

Similarly in complex systems development that are loads of tasks that do not naturally relate to any particular user feature. These end up being shoehorned into artificial 'development user stories' often defined after the fact. This is really bad because adding to the total story points for a product or feature late into the project for work that does not directly contribute to the delivery of a user required feature interferres with project completion estimates.

Emmanuel is absolutely correct. In Scrum the backlog may contain work items of different types, they do not all need to be stories.

That article by Mike Cohn 'The difference between a story and a task' is utter nonsense. Mike starts off by stating that a story is something that multiple people contribute to (which is wrong), but the first commenter disagrees and says instead that a story is something that delivers value to the end user (which is correct), Mike then agrees with that commenters definition, completely contradicting his own article.

As a general principle I think it's important for software tools to enable what the user wants to do, not try to force the user to do what the software wants them to. In the case of a project management methodology that is expressly intended to be used flexibly and pragmatically by teams in the way that works best for them that principle is doubly important. So it's disappointing that you don't recognise the importance of that.

[AndersMadsen]

Can tasks (not stories) be shown on a board when using the Kanban template? How?

No, kanban only works with stories, you only can view tasks in the story detail page or if you enable scrum in the sprint taskboard panel.

How can the user story details screen (to manage tasks) be accessed from the Kanban user story board?

Clicking in the name of the story in the card.

As far as I understood it Scrum/kanban are just templates and Taiga is a tool you customize so it fits your development.

[ProgBot]

Tasks are now shown, but it would be really nice to see the progress of issues in sprints.

[joshhopkins]

Thought it was worth mentioning here that we often add tasks not related to a user story, within a sprint (unrelated tasks are at the bottom of the sprint view). This is great for adding tasks outside the scope of any of the sprint's user stories. The only issue I've had with this is moving these unrelated tasks across to another sprint... but this obviously should be avoided anyway.