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.
Related
On my Kanban board project I have the option to add swimlanes on the Features where all the product backlog items are and another option on the Stories side.
Which would be the approach of each of them and why should be their separate use.
For example, I have on my Feature option an Expedited lane, does it make sense to leave it there or that options is more a swimlane that belongs to the Stories option?
As you can see I can set as many swimlanes I need, I found useful to have for example one swimlane per project on the Features option if I suppose to work with more than one at the same time, but in the other hand it gets me confused because I have the same option on Stories
Usually we use Product Backlog items(PBIs) to represent the work you want to develop and ship. You track bugs, tasks, and blocking issues using the bug, task, and issue WITs. To support portfolio management, teams create features and epics to view a roll up of user stories within or across teams. We usually map some PBIs under feature. The Feature could be the Parent of PBIs.
The Expedited Swinlanes could be used to both at Feature board or Stories Board to track those workitems which are urgent. For more details, you could read this document: https://www.visualstudio.com/en-us/docs/work/kanban/expedite-work#types-of-swimlanes
You create Swimlanes for each project also makes sense. In the Stories board, you could also create swimlanes the same like the Feature board to divided those workitems. But I suggest that you could create a team for each project, move those corresponding workitems to each team. Or you could create Areas for each project, using Area to distinguish them
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 will be using TFS 2012 and I am confused as to how to setup work items for one job where there are dependencies to the steps needed to get the job completed. For example, if the job first needs to get feedback from the end user, then a developer needs to build the base classes. After the base class work is completed then another developer needs to build the UI components. After the UI is completed then the tester needs to test the work. This job requires multiple people, including more than one developer. Each step cannot be started until the prior step is done. Should all of these steps be different work items or all in one work item? If multiple work items, how do you have the work item show as ready to work on for the next person when the prior work item is completed? If only one work item, then how do you handle the steps for multiple developers? This is one example. There could be the case where we have five developers all dependent upon each other before they can start their own work.
It sounds like you're trying to fit TFS into a formal waterfall process. It probably isn't going to be a good fit in terms of creating Gantt charts for you. In TFS you can use the hierarchy of user stories and tasks to accomplish half of what you want. For the other half you can create the appropriate link type between the tasks.
However, TFS isn't going to give you a Gantt chart like view for them, it isn't designed that way. If you really want to manage projects in this fashion, I'd look at integrating TFS with MS Project and/or Project Server.
As an aside, I would strongly consider just having those people talk to each other rather than relying on a tool.
As long as your performing an agile process your on the right track. Sprints should be based on PBI deployment, not completed tasks. If you find yourself pushing a PBI across multiple sprints, you may want to break-up your PBI. It is better to do this than keep wondering if your team is getting things done, since a group of tasks are moving into a new sprint. Getting a PBI to completed at the end of a sprint should be a key goal for an agile team.
Assign all the tasks needed to complete the PBI. Tasks should be created by the team together. This will help decide how to break down the tasks. I would break down the tasks mentioned into independent tasks based on functional groupings (UI, Business Model, ect). The art of this is to not break them down too much. The team will decide this for themselves. (remember to keep agile and let the team make short-term mistakes if it will help long-term: estimation, scope, quality, ect.
Assign QA tasks with unique names for each PBI. Don't use QA for the task name, it can become difficult to prioritize on the Board view. If you have a test team, let them create there qa tasks. Agile is agile (the team is the team).
The other main key point I learned was don't move on to tasks until the PBI has been planned completely, don't move on to sprinting until the tasks have been planned completely. This will help ensure that once your are sprinting, your not making decisions for that sprint in the middle of the sprint.
I hope this gives you some pointers.
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 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.