Loading Profile...
Epic Stories??
I'm evaluating Pivotal for managing our backlog and am looking for the ability to add epic stories to the backlog for the future and break them down into stories over time
I’m Undecided
10
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
-
Inappropriate?Hi, Tracker doesn't currently support epics, but we're planning on adding that in the future. Not sure of the time-frame yet, but it's a fairly high priority feature for us.
1 person says
this answers the question
-
Inappropriate?Glad this is a priority. When working as a combined team (from CEO to developers), we need a way to prioritize and track epics (and themes - for which labels work really well) to drive big picture prioritization. Combining this with stories will let us see how this is progressing.
There also would be a lot of value for our team to be able to manage tasks in the context of stories. For us, there are UI, DB, etc. tasks required to implement "as a role, I want to..." stories. These can be handled by different people. When managing team execution, we reason about tasks, but when managing the product, we reason about stories.
I’m optimistically waiting
-
Inappropriate?Hi Scott...we're thinking of adding a simple task list, contained in a story. Would that address your needs? Also, has your team considered finer grained, yet functionally complete stories, to reduce the need to break them down futher for engineering purposes?2 Comments Add a comment
This answers the question
-
Darn it. lost the long response when authenticating for GS. Will type again, but less wordy :)
1. The sizing of the stories is a function of atomic deliverability of value, not an inside-out view of how many tasks are associated with them. And "migrate the db" is a good task example, not a user-perceivable capability. One of the things to keep in mind is that the implementation team is not the only group using the tool. Providing that "outbound" view of what is going to be delivered, and which story is more important than the next; are both critical elements to the company working effectively, not just the implementation team working efficiently.
2. Make sure your task list allows tracking of "completion" - the existing states for stories will probably work fine. Ideally, each task can be estimated too (fib. / lin.), and those estimates can later be reconciled with initial story estimates providing more insight into velocity / release forecasting. -
Any updates on this one?
-
Inappropriate?I think it's a good idea to reduce the stories, but I have the same issue with this as I do with tracking bugs in Tracker. Specifically, I can't mark a bug as a duplicate or reject it with a reason very easily. And, how do I easily reference the other story/issue/bug? I realize there's a URL but, well, ugh.1 Comment Add a comment
This answers the question
-
story cross-referencing, yup - definitely an issue. probably should be another GS thread
-
Inappropriate?Yeah, this is a pretty high priority item for me. I won't be able to track a backlog without being able to create course-grained stories (epics) that will be broken down later to be scheduled in a sprint/iteration. It might (eventually) be good to have a max estimate for stories that are going into the current "pile".
-
Inappropriate?Another point to think about is estimates for epics. Currently individual items' estimates can only be one of the few values hard-coded into tracker. This is ok as it encourages making several small items rather than 1 big one, however when putting an epic into the backlog I would like to say if its a 20, 40, 100, or 200 point epic. We use fibonacci so 1,2,3,5,8 would be for individual items and 20,40,100,200 would be for epics. An epic would never go into a sprint however. Actually thinking about it now tracker could give a warning when an epic is approaching the top of the backlog. Because if an epic reaches the top of the backlog, and can't go into the next sprint, work must be halted to break down the epic. The warning could be similar to how a release shows up when its at risk.
I’m wishing this were hear already.
-
Inappropriate?Our team creates an epic story in the icebox as a means to just keep things on the radar. Then, we break it down into granular stories. However, we're wondering, should we delete/cancel the epic entry once we start creating the granular stories? I assume it's ok to leave the epic in place until it's considered complete. We use specific syntax in our descriptions to visually associate all the tasks related to the parent epic story.
Maybe a story type of "epic" would be useful, and it could somehow have logically associated stories. -
Inappropriate?We tag epics as epics, and don't bother with heirarchy, instead, when the epic gets to being broken down, we convert the epic to release (they should be called milestones) and make sure all the break-down tasks for the epic are above the release in the backlog.
Works pretty well for us, but the our epics are still deliberately small stories. As small as they can be while still being useful to the customer.
I’m confident this approach works better than you might imagine
-
Inappropriate?Hi,
I think more than having support for Epic Stories would be excellent to support nested stories. I know you released a fix to support task into stories, but what about bug trace to particular stories? What about Epic stories or associate chores to previously defined stories, etc? I'm sure there's more cases where nested user stories more than just tasks are needed.
I’m sad there's no support for Nested Stories
-
Inappropriate?I concur with Evan's epic story suggestion above; epics should have large (20, 40, 100, 200) point values, possibly should allow arbitrary values, should be allowed in the backlog for sketchy release planning purposes, but shouldn't be allowed into the current work period.
I’m prepared to sell my eyeteeth to have this feature right about now.
EMPLOYEE
