I am preparing a Kanban board for my team, and under an Epic, you can create three different kinds of issues: Stories, Tasks, and Bugs.
I discussed with my team whether a Technical story should be a story under Epic or a task under Epic.
Their point being is a story is more on business-related "user story" (not the technical story), and that technical story should fall under Task with subtasks.
As for me, I've gotten used to Scrum boards in different platforms having a technical story as the story, and we create tasks under it.
The subtask of this so-called technical story will contain the following:
Setup/Configuration
Investigation
Check-In/Deployment
Testing
Documentation
Whether we create it as a task or a story, I think the process will be the same anyway, but what would you guys recommend we use?
Related
I have stories with subtasks (we make heavy use of them) I would like
1) That when all sub-tasks of a story are done, the story moves alone to done
2) That when a story is moved (for instance) from "Idea" to "Backlog", or from "Backlog" to "Ready", all its sub-tasks move with him. So in coders language, that when a Story is moved by dragging the story, all related sub-tasks status get's overridden by the new story status.
The boards structure guarantees no problems since the PO has only one colum for all development status (dev, review, etc) and development scrum board has only status those dev, review, etc colums so .. Everything should be Ok
Furthermore the PO board is only viewing stories and using Epics as swimlanes so he cannot see the sub-tasks moving. And the developers board is only showing sub-tasks using stories as swimlines.
So developers cannot move the stories to Done.. only the sub-tasks.
Can do all this through validators on workflow transitions
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
I have just upgraded an on-site TFS installation from 2013 to 2015. We will be changing the working with bugs setting to Bugs appear on the backlogs and boards with tasks instead of on the backlog board.
In the following image, we can see the Yellow task icon, along with a the number of tasks completed. However, there is no way to see if the item has any bugs associated with it.
Is it possible to see bugs in the same way as tasks or to indicate if the item has any bugs?
When you track bugs similar to tasks, they’ll show up on the sprint backlogs and task boards.
When you track bugs as requirements, they'll show up on the product backlog and Kanban board.
You are tracking bugs similar to tasks, but you are checking Kanban board, so you can't see bugs. You need to check task boards.
After a couple of days of searching, it appears you cannot do this. You can have Tasks showing in the Item, but not Bugs.
If you select Bugs appear on the backlogs and boards with tasks, the only way to see the bugs is on the task board and there is no indication of open or closed bugs on the Backlog Board.
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)
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.