We are using Jira / GreenHopper to run our sprints on a Scrum team. The fact that Jira is a bug tracking tool and GreenHopper is a Scrum-ish add-on is becoming painfully apparent.
We want our Product Owner to enter user stories in Jira/GreenHopper and have the team hang technical tasks onto the user stories. How does one do this? Jira/GreenHopper does not seem to have any notion of user stories with tasks. Is this correct or am I missing something?
Also, we want the task board in Jira/GreenHopper to track the user stories and tasks as they move from To Do to Done. Again, there seems to be no way to do this. A User Story is Done when all of its tasks are done. Tasks should be able to move from To Do to Done while the User Story is In Progress. Are we correct in thinking that the Jira/GreenHopper task board cannot do this?
I am generally interested in any thoughts, books, tutorials, etc. on how to use Jira/GreenHopper to solve the above issues.
A lot has to do with how you set the tool up. Jira only allows one level of sub-task, so you'll have to make the Task type a sub-task type. That will allow you to associate the sub-task to the Story. When I had Jira/GreenHopper on a project in the past, there were a lot of manual steps that I had to take to get it set up--but it was exactly the way I wanted. The installation is a lot easier now, but you lose some of that insight from doing the configuration yourself. Check out the following guides to get things customized the way you want:
http://confluence.atlassian.com/display/GH/GreenHopper+101
http://confluence.atlassian.com/display/GH/Specifying+your+Project+Templates
http://confluence.atlassian.com/display/GH/Setting+Up+Epics+for+your+Project
I wish I could do better than this. Jira is very configurable, and their online help is usually pretty responsive in my experience.
In addition to what Berin notes, stories can be moved to done:
Visually on the task board, by using the Compact task-board mode. (This mode can be turned on through Views: Task Board Modes: Compact(Kanban).)
Via the "Resolve Issue" and "Close Issue" workflow-steps available on the story detail pane.
Related
I have been using Rally for Project Management in my previous organization, and now I have to use Jira Agile for the same job in the new organization. I am having hard time understanding the way JIRA Agile works, and could not get a hang of the tool after a week of struggle. I am sorting expert help for what I would like to achieve. I have been using JIRA for many years as a bug logging tool but not as project management software.
All I want is to create an Epics and Stories, schedule it into a particular release or sprint. On Rally this is straight forward. Few images attached here.
I could also see the burn-down once I do the above setup, and the developers/qa start burning down or burning up the hours.
I could not achieve the same on JIRA. It asks me to create a scrum board, but I don't have a clue on how to add the child tasks to a story without creating a new child task (which I don't prefer as the tasks were already created and few started progressing).
The scrum board is also not the way it is on Rally, as it does not list the stories but directly shows the tasks which I am unable to correlate with the story. Can any one point me to a proper tutorial or assist me based on your experience in JIRA? Thank you in advance.
I can recommend two things that might make it a bit more easier for you to transition from how you structured your projects before: the Jira plugin "Structure" and using epics, stories and sub-tasks in a defined and controlled manner.
About the plugin: Structure allows you to define a structure, a container that may even span multiple projects, and lets you put issues in. Secondly, and more important, it allows to create any number of sub-task levels. You can use the structure view to show and hide sub-levels, or if you use the agile boards you can just apply a quick filter to the board.
The same goes for using epics, stories and sub-tasks, just make sure everyone able to enter issues follows the same criteria and then add some filters.
Hope this helps a bit
You may want to look at https://confluence.atlassian.com/display/AGILE/JIRA+Agile+101 - it should cover most of the basics to get you going.
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)
I'm looking for a work-item-tracking/bug-tracking system (or JIRA plugin, or TFS plugin, or...) which makes it easy to stack-rank work items without having to manually assign priority values to each work item.
Instead, our team wants to be able to see a list of open work items and be able to drag-n-drop one or a multiple selection of work items until the order matches the team's prioritization. This would be much easier than arguing about priority numbers and dealing with ties (e.g. "which of the 5 bugs marked priority=2 should I work on today?").
Our team is considering switching work-item-trackers (we use Gemini now) and availability of a good drag-n-drop prioritizer is high on our requirements list.
I realize drag-n-drop ranking is non-trivial because no team will stack rank all work items. Instead, we'll want to take a subset (e.g. work items for one sprint sprint or iteration, or bugs assigned to one developer) and stackrank those, then later look at a different subset and stackrank those, etc. And I'm sure we'll sometimes need to mix and match different stacks, so there'd need to be heuristics (ideally configurable) about how to show a stack of items previously stacked separately.
Pivotal Tracker is close to the drag-n-drop UI I'm thinking of from a UI perspective, but Pivotal's model of separating user stories from the underlying work items (plus a few other issues) doesn't match how we want to work. We don't want to have to deal with different artifacts (stories vs. JIRA/BugZilla work items)-- instead we just want a drag-n-drop UI to automatically fill out a "priority" field in the issue tracker, and which we can use later when sorting and filtering. And we wouldn't want to use Pivotal as our only work item tracker, because it seems to lack common features like bulk editing which are critical for large projects.
Anyone know of a tool like what I describe above?
Urban turtle is the best TFS add-on, making ranking/prioritizing a sane activity. Priority by number is a disaster so don't think you're alone there.
http://urbanturtle.com/
Urban Turtle is updated every month and used by quite a few teams including a number of my teams.
Eylean Board has what you are looking for. They offer a task board where the tasks are prioritized by moving them around, the priority tasks being on top. Interface is nice and clean and they offer other features such as integration with TFS, reports, etc.
The greenhopper plugin for JIRA has this feature. It's worked well for me ...though I'm not a big fan of JIRA in general.
http://www.atlassian.com/software/greenhopper/tour/backlog-management.jsp
Previous to this, I just used excel.
One of the best (and fastest) web UI's I've seen is on AgileZen, which supports something similar to this. Last I knew it did not have built-in integration with TFS, but it does have a REST API. It's basically a web-based, shareable Kanban board.
In the default TFS setup there are three work item types: scenario, task and bug. That last one is quite straightforward, and task also: it's a specific job for a team member to complete. But I think scenario is a bit vague.
I usually create a scenario for larger and more general units of work: for example "Create functionality to add employee lines to an employer." Smaller, more specific work items would then be tasks, for example: "Create detail form.", "Create save method on server.", etc
When I check in changes I link the changeset to the scenario AND to the specific task. Is this a good habit? How do you deal with tasks and scenarios? Any resources to best practices?
I've also heard scenarios are actually meant for use cases, is this so?
Scenarios can be any user story.
You only need to check in to the task.
When tasks are created, they should be linked to a Scenario first, before assigned to developers.
That way the association between checkins and scenario is automatic (and reportable).
No point double handling
In the MSF Agile template, Scenarios can also be thought of as "User Story" - kinda like a lightweight agile use case.
The Scenario details the broad picture of the functionality that is wanted to be implemented, recording a single path of a users interaction with a part of the system. For example, in Stack Overflow a couple of Scenarios might be "Ask a Question" or "Answer a Question". Scenarios and Quality of Service Requirements can be thought of as top level work items in MSF Agile (i.e. the work items that define the system) with Scenarios being functional requirements and Quality of Service being non-functional requirements.
I tend to create multiple tasks from each scenario and typically only record my check-ins against the task. In TFS 2010 properly hierarchical work items are coming which will make this way of working easier to report on. Currently work item associations are bi-directional (i.e. you can say that a task is associated with a scenario but you cannot say that it is a child of it).
There is nothing wrong with marking your check-in against the task and scenario, just that it creates more work for you when checking in. Also, the scenario might be getting delivered by a number of developers were-as a task tends to be down at the granularity of individual person activities.
If you are doing a lot of associating of a work item to a scenario, then the following tip might be handy for you (http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html). It shows you how to modify the standard MSF Agile process template to remove the ability for check-in's to resolve the Scenario but just associate the check-in with that work item. Resolving on check-in for a long running work item like a Scenario is nearly always not what you want to happen - but is the default behavior out of the box.
Hope that helps.
If by "default TFS setup" you mean the "MSF for Agile Software Development" project template, then a scenario is defined as follows:
A scenario is a type of work item,
recording a single path of user
interaction through the system. As the
persona attempts to reach a goal, the
scenario records the specific steps
that they will take in attempting to
reach that goal. Some scenarios will
record a successful path; others will
record an unsuccessful one. When
writing scenarios, be specific as
there are many possible paths.
To get a bit more info on this, have a good look at the "Documents/Process Guidance" folder under the project in team explorer - it explains the recommended process fairly well
You can think of scenarios as representing the users perspective, whereas tasks are the developers perspective. According to the MSF Agile documentation a scenario "represents a single path of user interaction through the system you are building.", and a task "identifies a specific item of work for a team member to perform."
Tasks can be linked to scenarios. When checking in you, as a developer, have solved a task, not the scenario, so you should relate the changeset to this task.