Needing a way to convert Tasks to User Stories or Assign Points to individual Tasks

[jaxca...@gmail.com]

I'm developing an Isomorphic React Application and have user stories such as :

Login Component, Logout Component, Nav Bar, Add Images To A Gallery, Delete Images From A Gallery etc..

Each of these are described from the perspective of the end user such as :

Login Component : Users will need a login/register area so they can access their private galleries and content. This should be located in the Heading Component.

The problem begins when Tasks are added to define the STEPS involved in completing this User Story :

#15 Create Display Component for Login & Register View

#16 Style Display Component for Login & Register

#17 Create Basic Login & Register View Component

#18 Establish Routing for Login & Register View

#19 Configure Passport for Social Login

#20 Configure Users Table in PgAdmin for PostgreSQL RDMS

#21 Configure Session Management

#22 Finalise Login & Register View (smart logic) Component

The first task will need to be completed in order to approach the second task.  It doesn't make sense to begin the second task for this User Story until all First Tasks in All user Stories are completed since it's difficult to begin styling DOM Elements to look just right when not all the elements in a component have been created yet as it will mean going back and re-tweaking that content over and over whenever a new DOM Element is added.

So there are a few easy ways to resolve this :

1.) Allow Tasks to be Promoted into User Stories

Not a good idea since "Create Display Component for Login & Register View" is NOT a User Story.

2.) Allow the Assigning of Points to Individual Tasks by dividing up the total points dedicated to a User Story.

When a Task is completed it will now track progress more accurately.

3.) Allow Tasks inside a User Story to be added to a Sprint.

This is the best option as it allows for the proper breakdown of User Stories so developers can tackle a healthy quantity of Tasks in a Sprint instead of being forced to complete entire User Stories even though doing so will result in double-handling and additional, illogical, unnecessary work later on. 

[Alejandro Alonso]

1.) Allow Tasks to be Promoted into User Stories

Not a good idea since "Create Display Component for Login & Register View" is NOT a User Story.

2.) Allow the Assigning of Points to Individual Tasks by dividing up the total points dedicated to a User Story.

When a Task is completed it will now track progress more accurately.

3.) Allow Tasks inside a User Story to be added to a Sprint.

This is the best option as it allows for the proper breakdown of User Stories so developers can tackle a healthy quantity of Tasks in a Sprint instead of being forced to complete entire User Stories even though doing so will result in double-handling and additional, illogical, unnecessary work later on. 

Hello Jax, I think actually only the option 1 fits in the Taiga scrum approach, we have an existing enhancement request to include it: https://tree.taiga.io/project/taiga/issue/2773

Taiga follows the standard scrum practice about it considering story points as a high-level estimation of the complexity (made before sprint planning). It's conceptually different from the task-hour that just measures the the total effort to complete a user story.

This article from the Scrum Alliance reflects the actual Taiga point of view about it:https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours

Most teams doesn't even need to know this task-hour value so Taiga doesn't support it by default (in this article you can find the Taiga alternatives to achieve it (https://taiga.io/support/why-is-there-no-time-tracking/)

Regards!,

--

Alejandro Alonso Fernández   CIO & Co-founder alejandr...@kaleidos.net  | Tel: (+34) 627263808 | (+34) 913562995 www.kaleidos.net/FC8EAC/

[jaxca...@gmail.com]

Hi Alejandro,
I agree with the way Taiga uses a point system to generate a quick estimation on User Story Complexity and see that if you want to extract that information it's still there even if not immediately obvious as you also linked to and I've previously read.

However, Tasks are from the perspective of developers and define the individual steps required to complete a feature within the project.  User Stories are from the perspective of the User and look at what features they will need access to in the completed project.

Trying to pass a Step by Step Task off as a Declarative User Story doesn't appear to be a good way to go as it is counter intuitive even from a basic point of view when considering you are trying to make something that is NOT a User Accessible Feature Declaration .. into one.

That article you link from the Scrum Alliance is counter to what I've seen possible inside Taiga since Taiga works on Points and not Time for estimations.

If you look in the comments section there are 2 comments in there which I'll quote here that make a lot of sense : 

Rick Tonoli, CSM, 9/1/2012 10:34:15 AM
We've found what we think is a good use for junction between story points and task hours. When we plan we use the task hours as a kind of "check sum" for the story points to point out inconsistencies. For example if you have a low point story, but it has days of tasks, that tends to point to a problem with story point estimation and should trigger a re-vote on it's value. Also we've found from the months of data we have that stories of similar value tend to have similar hours (I did not expect this), however because this is was not true in some cases, we tend not to use it as a rule of thumb.

AND

CURTIS REED, CSP,CSM,CSPO, 7/29/2015 1:23:01 PM
Cheng, I enjoyed this post.
I have often heard that points and hours are not related, it is a common refrain, but I happen to disagree with it. I accepted and believed it for a few years but the more experienced I became the more I realized it was a bit misleading. 
The reason we estimate points at all is for what purpose? The team is applying a QUICK estimate of the size of each work item that the product owner wants to get done within a Sprint. 
What is a sprint? It is a TIME BOX. 
Therefore, we must be able to determine that the number of points we have assigned correspond generally to a story size expressed not just in "complexity" but also "duration".
If a team has 5 members, then 5*40=200 hours of available time per week, or 400 hours available. 
If the team says "we can complete 50 points in a sprint", then 50 points BETTER correlate to less than 400 hours in a two-week sprint.
It is therefore, illogical and misleading to say that POINTS and HOURS are "mutually exclusive" concepts.
The elephant analogy is charming but I think it is misleading. 
Why? Because we do not estimate stories to determine WEIGHT but rather to determine how many points of work can be completed within a TIMEBOX.
I would rewrite the elephant analogy by saying that a tribe must determine how many elephants they can eat in a specific period of time (2 weeks). The tribe estimates that they can eat 3 baby elephants, or one cow elephant in a two week period, but cannot eat a bull elephant within that period. Now we see that the analogy IS dependent on time.
This seems again to support your article, and my belief, that there is a general CORRELATION between point value and later the task hours. 
I look forward to hearing differing opinions.

 Considering the logical perspectives from the above quotes from the comments section of the article you provided a link to, Option 3 is perfect because :

• You still just use a Points system to estimate general complexity of user stories
• You check-sum this by designating points into individual Tasks (steps required to complete a user story from the developer's perspective)
• Tasks are typically added after initial User Stories are defined and so designating available points to individual tasks will help refine a more accurate representation of User Story Complexity
• Ability to designate Tasks into a Sprint instead of User Stories means that double+ handling is avoided
• Teams will gain more accurate feedback on performance by seeing project completion values increase more frequently than once per huge User Story.. this helps maintain team motivation as well

I think Option 1 would be the quickest way to get the job done considering the existing structure for Taiga.. but not the most accurate way in terms of project management structure, estimations and coordination.

Thanks,

Jax

[Alejandro Alonso]

Hello Jax,

Thank you very much for such an elaborate answer, it's a really helpful feedback for us. We will have to review internally this topic again with all the info provided to take a decision.

Regards!,

--
Please help us keep the Taiga.io Community open and inclusive, follow our Code of Conduct:
https://github.com/taigaio/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
---
You received this message because you are subscribed to the Google Groups "taigaio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taigaio+u...@googlegroups.com.
To post to this group, send email to tai...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/8ad9fc59-b223-47f6-b582-dc828d00ba34%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[jaxca...@gmail.com]

Hi Alejandro,

Thank you for taking the time to review my feedback and for providing such a useful tool for development management.  In my feedback I was meaning that the combination of Option 2 + 3 would provide that ideal solution, Option 2 or 3 on their own would get by but 2 + 3 would provide the ultimate in terms of managing User Stories and Task breakdown within appropriate Sprints.

Thanks,

Jax