Twoje komentarze
I would also like this feature, but honestly I haven't used JIRA much yet (my dev team has recently adopted it) so I don't have any real ideas about how I want it to work :-)
10 lat temu
To me this seems like something that should be done when they get put into the sprint.
I definitely like it to be restrictive.
You can drag and drop them to adjust their order. There is no explicit "priority" data field.
I voted for this even though I'm not 100% sure it's what I want. Here's my issue:
Our structure is:
PRODUCT > EPIC > FEATURE > USER STORY
Easybacklog's structure is
BACKLOG > THEME > USER STORY
This means that I have to collapse two of our levels to use this product. It also affects how I can calculate velocity since each backlog has its own sprints and stats.
In order to have better stats data, I would want to use a backlog to manage a single project. However, that means I have only two backlogs (at this point) and a proliferation of themes.
On the other hand, if I set up PRODUCT+EPIC as the backlog, my features become easier to manage. But now I have many separated set of stats and sprints.
Our structure is:
PRODUCT > EPIC > FEATURE > USER STORY
Easybacklog's structure is
BACKLOG > THEME > USER STORY
This means that I have to collapse two of our levels to use this product. It also affects how I can calculate velocity since each backlog has its own sprints and stats.
In order to have better stats data, I would want to use a backlog to manage a single project. However, that means I have only two backlogs (at this point) and a proliferation of themes.
On the other hand, if I set up PRODUCT+EPIC as the backlog, my features become easier to manage. But now I have many separated set of stats and sprints.
I wouldn't do this. It seems like it's mixing tech ops concerns with backlog concerns. On the other hand, I see the point about the cost issues.
I think it's fine as-is. I would just write those stories as "so I can NOT shoot myself in the foot ..." or "so I can be prevented from ..."
I would rather see this done by integration with a tool more oriented toward task-based work, such as JIRA. Even a simple story could cross boundaries - requiring an API in a system managed by another team, for example.
I have no need for this right now, but I can see how it would be useful when attempting to determine priority. Being able to sort based on a weighted value could be very helpful. For example, we often try to prioritize based on story size vs. business value. Small stories with high business value would pop to the top, for example.
I would think long and hard about adding a feature like this. Once you get into detailed tasks, you will start being asked for integration with version control. It will never end.
Instead you might want to consider integration with other trackers out there, such as JIRA. Then this would be entirely optional and would not affect the user experience unless it was turned on. And the complexity of task tracking/version control/etc. would be moved to the external product.
Instead you might want to consider integration with other trackers out there, such as JIRA. Then this would be entirely optional and would not affect the user experience unless it was turned on. And the complexity of task tracking/version control/etc. would be moved to the external product.
Customer support service by UserEcho