using jira 6.0.5, in green hopper, i want to configure agile board which should show me all linked bugs over agile board. infact it should show me as below:
1. story (sprint stories) //its there.
2. how to include all bugs which are raised during these sprint over the agile board. ??
3. any other linked Task with stories should also appear on agile board.
As above point 2 and 3 are the story related raised tasks so, it should not be estimated or add into greenhopper sprint as these are already part of the Sprint through "Story".
I just want these to appear on greenhopper - agile board.
please tell me how it could be configure ??
is it through "swiamless" in configuration then plase share me its jql query, i tried - "issuetype=bug" but not worked.. no change..
You will probably need to change the issue filter for your greenhopper board. You can do this in the configuration screen of your greenhopper board.
You will need to change the filter so it includes all the issues you want to see on your greenhopper board (stories, bugs, tasks) . Then you can start using the swinlanes to indicate the differtent types.
Here is some more information about Greenhopper and filters : https://confluence.atlassian.com/display/GH/Configuring+Filters
its already configured as project = "project name" ORDER BY Rank ASC" and no any filter applied for story or any issue type. so, i can see all issues in backlog. but that is not a problem. problem is , i want to see story bugs raised during sprint to appear on agile board. and no any configuraiton is found in swiamless to achieve this...
no, its not feasible. These are the bugs raised during sprint execution days and its just while story in QA. so, actually, it should not be planned or created as a subtask. Actually, on manual (without software) agile wall, we just keep it on postix for visibility of task . But in green hopper, i could not find any interface which allows me to make them appear on agile board...(not to include in sprint backlog explicityly as it will consider as a scope change and also, not as a subtask because , this is bug only).
Additionally, also these bugs are part of the story itself as these are raised while QA the story so, story can't close until these bugs resolved. so, there is no any case to move bugs to next sprint or add them to the sprint as these are already part of the story. so, just need a mechanism on configuration which allows to appear all linked bugs to appear on board so,it makes complate picture on agile board.
,i am talking about "story bug" , its not a subtask exactly. it is issue type equal to "bug" and found while testing story so, saying "story bug".
(also, i am talking for single project, one sprint - simple).
1. sprint 1 - story 1, story 2, story 3. (3 stories existed in sprint backlog).
2. sprint length is 2 weeks.
3. sprint execution days - story 1 development completed and its in QA. Now, QA found 1 bug while doing testing of this story 1. so, QA linked that bug to story 1 as 'discovered while testing'.
I want this bug to appear on agile board.
REASON: this bug is part of the sprint only as it is related with the story and linked with story.
can we show such story linked bugs to appear on agile board ? it is just the case to layout agile board in such a way to make appear such linked bugs on agile board.
The way Greenhopper works is not through issue links but with sub tasks.
So those linked Bug Stories will never be automatically added to your Sprint. You might be able to do this with the Bonfire plugin, but I'm not entirely sure.
Those Bug Stories should appear in your product backlog, so you can add them to your Sprint manually (just drag and drop them in the active Sprint).
ok... but manually added bugs in sprint are actually consider as "scope change" as sprint backlog changed while sprint in progress.
its not correct way. bugs raised for story would be part of that story only and also, story estimation has already included all these time.
looks like, its not possible in agile board for now.
This sounds like the same requirement I have.
I have my Scrumboard arranged into swimlanes. I thought (hoped) that "Base swimlanes on" - Stories would created a swimlane for each story (it does) and in this show every issue connected to that story (except epics) (it doesn't).
We arrange swimlanes by story, so we can see at any time the state of every issue connected to a story, so we know exactly what work is left to do to complete each story.
This is also to enable management to maintain stakeholder expectations ("what are we likely/actually going to deliver this sprint?").
I have 2 stories in a sprint. Each story contains acceptance criteria & enough info for devs to do work. Some additional dev/qa tasks may be created and linked to the story (we don't use sub-tasks historically) with link type 'related to', or maybe even 'blocks')
Bugs for each story will be created during the sprint. These will be linked to the story (with link types being 'found while testing', or possibly, 'blocks').
I want the bugs, tasks, sub-tasks (every issue) related to a story to be visible in the swimlane for that story.
The ability to do this in a lightweight manner is an important requirement here. Having to manually set up and maintain a bunch of JQL queries (one per story) in order to get this view is aborious if we have 15 stories every sprint, and prone to error since it's a tedious manual task.
I was very happy to see Story apear in the Group By list, but disappointed that it seems to only recognise the story itself and sub-tasks as belonging to a story (and only if the story actually has sub-tasks - which ours don't). Everything else gets booted out into the big generic pile of everything else.
Currently we have to set up a query like this for each story:
issuekey= StoryID1234 or ISSUE IN linkedIssues("StoryID1234")
It would make life easier if the setting "Base swimlanes on" - Stories actually enabled this automagically.
Why don't you just return the Story back to development if you find bugs in the story. We simply have our testers add bug comments to the Story and return the story to Development.
At the end of the sprint we determine if we want to implement the story as-is and either create a new story or bug. This makes things much easier. Why does this easy approach not work for you? The only negative is you may take a big hit to velocity if you move an unfinished story to the next sprint. But then you have a big point count in a subsequent sprints so it averages out. Thoughts??
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot