In VS2010 Scrum 1.0 project template, can I create a PBI that has child PBIs? If not, what is a good alternative for large user stories aka product backlog items?
The short and simple answer is yes. You can create a child PBI. Quite simply, under the Links tab, you add a new (or link to an existing) PBI work item.
The greater question is: Why do it?
Strictly speaking, from a Scrum point of view, you shouldn't have hierarchy in your user stories. The stories, as Mike Cohn (I believe) put it, you should INVEST in good stories. The 'I' stands for independent, which a story can't be if it is the child of another.
The only "Scrum-appropriate" reason to introduce a hierarchy is when you're breaking down a large story into small workable stories, or (rarely) molding to overly-small stories into one story of reasonable size.
Assaf.
You can do it, but like Assaf poitned out... why do you want do it? Large stories should be decomposed into smaller stories... stories that are small enough for the team to complete (done-done) in a single sprint.
Related
We're still fine-tuning our ALM process using TFS 2015 Update 1 On-Prem. We are using the standard SCRUM template and we display bugs on the backlog, along with requirements. Bugs are reported by the business and go through the same level of analysis as PBIs in that they will contain child tasks:
Now for PBIs, when a tester is testing the PBI and discovers a bug with it (which needs to be fixed as part of this sprint), they will create a bug as a child to the PBI. This keeps them together on the task board. 1 PBI may have many bugs and these may be worked on by different people. These child bugs will have child tasks.
The process mostly works but on the Kanban board, the child bugs are shown, the parent PBIs are not. Why not? and how can I work-around this? I can link them differently but we want them to stay together on the boards.
Thanks
It feels like you're really mixing and matching the two supported scenarios here.
Personally I prefer not to create Bugs as part of the sprint (to me they're not really bugs if they haven't made it out of the iteration) and often it's used as a communication mechanism instead of dev & test working closely together.
If you want something on the board under the PBI/Bug, you could use a Task Work Item (or a custom type) and then use the funky card colouring on the board to look for a tag to signify that it's an in-sprint bug/issue.
Highlight work items based on custom criteria
I am filling the product backlog for a new product with user story PBIs. As I write, I realise that some PBIs are dependent on others being completed first. I cannot use the order of the backlog because it gets changed by others depending on client requirements. I want it to be obvious that one PBI depends upon another being completed first. Inter-PBI links are possible but it's not clear what a link between PBIs represents.
What is the best way to get TFS 2012 (in the cloud) using the SCRUM template to represent PBI dependencies?
Does anyone use hierarchical PBIs or tags for this purpose?
Thanks in advance.
There is a WI link type for Predecessor/Successor. This is how I typically do it. It doesn't make it super-obvious, but the information is captured somebody just has to go to the WI Links tab to see it.
I would recommend that you get all of the people competing for priority in the backlog to appoint a single Backlog Owner who understand the dependencies ( sounds like you). That person can then order the backlog taking into account both customer priority and dependency.
I have in the past added a Customer priority field to the PBI & Bug to allow the Sales\Customer Services guys to order that field to their hearts content in excel.
That way they are not interfering with your order but still providing the influential and valuable customer order.
As my scrum team does backlog grooming, we typically start with epic-level work, and refine those PBIs into themes and stories as part of normal grooming activities. As a means of structuring these work items, the PBIs that result from refining and clarifying other PBIs are created as child links of the larger items. We implement this process by assigning only sprintable stories to sprints, while leaving their parent theme PBIs in the current release iteration.
We've been slowly growing into the features provided by 2012 after an upgrade earlier this year, and the ability to drag items around in the Product Backlog view in Web Access (rather than manually tweaking priority values) is extremely attractive.
We'd like to use this, but there's a problem: PBIs that have a parent-child relationship, as do most of our planned work, can't be dragged around individually. Instead, each epic appears as a tree in the product backlog, enumerating its children with its own priority range of [1..1000000], and it drags around atomically.
With this in mind, how is this supposed to work? Am I missing something about the features of the Product Backlog view? Are we intended to be destroying our epics and themes as they're refined into smaller PBIs, so that the stories can be scheduled independently?
We've been struggling with the same type of issue. We decided to remove epics and only use stories. Then we tag each PBI with an epic name so that we can easily search and group items when necessary. Haven't really found any better option yet.
To manage the scrum development process of a big community website, we decided to move to JIRA/Greenhopper/Bonfire.
I have created elaborate Epic, Stories and Tasks, all well linked to each other.
I would like to develop the "Product Story" in more detail all the time by adding new Epics, new Stories to (new or existing) Epics, etc.
To be able to do this properly, I want to have a hierarchical overview of all issues: Epics, Stories, Tasks, etc.
Question: How do we set this up in JIRA?
Why?
=> My approach is from the point of view of project management: getting everybody aligned around the same vision. However, I think it is part for everyone in the team -especially for the ones who are actually building the product- to have a quick view of how their current or planned work fits into the big picture.
Stories have sub-tasks, which will be shown hierarchically in the Sprint, but all sub-tasks have to be completed in the sprint of the user story. I also think when you create a story you can specify an epic, which will create a hard-link ( the same as story -> sub-task). Is there a reason you want to use a Jira task? To me it looks that in a SCRUM environment you only need Epics, stories and sub-tasks. Maybe some spikes and support tickets from time to time.
Coming from a tool like Rally, I can appreciate you wanting to see the big picture. We transitioned from Rally to Greenhopper over a year ago mainly because of costs. Lets just say you get what your pay for. I haven't found the feature you're looking for in Greenhopper, it only has a single threaded view for things like Epics to Stories (on the planning page) or Stories to tasks on the (on the work page)
In a SCRUM Agile project we use TFS 2010/VS2010.
In the period before starting this project, the customer has already written out 80% of all the use cases. The issue is that most of these UCs are so large, that I want to split them up in user stories. The user stories can be compared to scenarios for the use cases.
My plan is now use the Agile process template and start creating top level user stories as use cases. Each top level use case will have 1 or more user stories as child beneath the parent user story. Then below the 2nd level user story I add one or more tasks where developers can do their checkin against.
Is this the right approach ?
Yes it is, the proof is that when you create a child work item from a User Story only two types are available: Task and User Story.
This is made to split big User Stories into a subset of smaller ones.