-
Bug
-
Resolution: Fixed
-
Low (View bug fix roadmap)
-
None
-
None
-
None
This issue will be used to capture all feedback on Spike 2 of GHS-1800.
[JSWSERVER-2568] GHS-1800 Spike 2 Feedback
Thank you all for the feedback, it is greatly appreciated.
Michael, as a rank field would be required for each Xproject we felt this would add complexity and confusion to the Custom Fields screen, and other configuration screens. Furthermore, we felt that having one issue in two backlogs does not make sense. When planning for 'XProject A' GHS-123 is at Rank 500 whereas for 'XProject B' GHS-123 is at Rank 1.
As such, we chose not to pursue a solution where one JIRA project could be present in only one XProject.
Thank you.
Nicholas
We have investigated quite some time to test the new XProject feature and realized, that this approach would give us the flexibility we have been searching for. Having the JIRA projects grouped together to have a consolidated view on our teams' work is a needed requirement, which will prevent us from moving to a different tool.
Our setup for testing looks like this:
We configured 5 XProjects
-Project A
-Team A
-Team B
-Team C
-Team S
The XProject "Project A" is just a 1:1 mapping of JIRA "Project A" to XProject "Project A", to evaluate the "old" usability of GH.
We assigned multiple JIRA projects to XProject "Team A"
-Project B
-Project C
-Project D
We assigned multiple JIRA projects to XProject "Team B"
-Project E
-Project F
-Project G
We assigned all JIRA projects from "Team A" and "Team B" also to "Team C"
-Project B
-Project C
-Project D
-Project E
-Project F
-Project G
XProject "Team S" consists of all JIRA projects, not assigned to any other XProject:
-Project H
-Project I
-Project...
In XProject "Team A" and "Team B" we created contexts for each JIRA project that is part of them. So the project manager can have a look at the planning board of his team and filter only the tasks of one specific project, to do his project prioritization.
"Team C" is an outsourced development team. "Team C" takes over specified tasks from both, "Team A" and "Team B" and therefore needs a dedicated backlog. In XProject "Team C" we created a context to filter the elements by assignment, to only have items in the planning board that are assigned to members of "Team C". So "Team C" has a backlog that can be prioritized separately from "Team A" and "Team B".
As soon as development of a project in "Team A" or "Team B" is completed, the projects get moved from the XProject of the team to the XProject "Team S" which takes care of support issues on a Kanban board in GH.
We made good experience with GREENHOPPER using this scenario and hope to have it in production as soon as possible.
Nevertheless we defined some improvements, which would make our lifes much easier.
Q: Sprint vs fixVersion, how does this assist your team/organization?
A: We like to see GH using a dedicated field for sprint iterations, because the solution of using versions as sprints is not clean and is leading to confusion at certain situations.
Q: How could the Sprint version be improved?
A: Sprints should be named Iterations to give it a more generic character. We want to use them for example for non-development tasks in projects phases before and after development (e.g. envisioning or support). Also some kind of graphical calendar overview would give great benefit.
Q: What else are you trying to find out with the Sprint version?
A: create some kind of "archived" sprint, to get rid of old items (same as versions).
Q: Do fixVersion charts have any meaning for you once you are using Sprint versions?
A: No, we are only interested in sprint results.
Q: What have we missed in terms of multiple project support?
A: each XProject should have default contexts to filter planning and task board per project. Distinguish between "XProject Team Member" and assignable users of projects (group them to "other")
Q: What makes it difficult to set up a new 'cross project'? Why? How could this be better?
A: a XProject should have a XProject Admin who can change the default Context of the XProject and a XProject Logo shown on the planning and task board, like project logos. Also a XProject should have default user preferences for dashboard appearance e.g. list view or number of visible items.
Q: What barriers do your teams have in using this? Where is it too complex?
A: -
Q: Where will your teams struggle with GreenHopper Spike 2? Why?
A: -
Q: Is this interface for GreenHopper more/less complicated? Where? How could we improve this?
A: switching between views on the planning board (Sprint, Version, Component...) and contexts, sometimes behaves inconsistent.
Q: What would you want converted to Sprints upon upgrade? How could we make the upgrade to multiple project support easier for you and your team?
A: We would like to map existing versions e.g. 'Sprint 61' to new sprint 'Sprint 61' and delete the corresponding version with a manual confirmation process.
Some additional things that came up while testing spike 2:
-Page previews on planning boards need to show complete issue ids, not only numbers
-some kind of freezing for active sprints, to prevent them from changes (like adding new stories)
-having an clear indicator for unplanned issues that can appear only at the top of the backlog
-changing the relationship between projects and XProjects need to respect sprint assignments (moving project X from XProject "TeamA" to XProject "TeamB" for one sprint should not delete "old" sprints from issues).
Regarding Nicks comment:
"In Spike 2 you have the ability to add one JIRA project to a number of XProjects. After further discussion we have decided that we will limit the multiple project support in GreenHopper to one JIRA project per 'Agile Project'. The name 'Agile Project' may not be final but it represents the XProject that was in Spike 2."
I wanted to say, that this feature is essential to us, if you read the text above. So maybe you should check if its possible to leave it like it is.
I hope I didnt missed anything, but looks close to complete. I would also like to get some feedback.
Regards
Michael
Showing the Agile Planning Board, for team Desktop - Server; their sprint 24 issues / stories.
Just my experience.
Menu: Administration -> GreenHopper -> Enabled Projects
View: Configure GreenHopper X Projects
Remark:
The here called 'XProject Name', I named these after my scrum / project
team(s). Which made good sence, also when then viewing in the Agile
menu. Using example 'Team Desktop - Server'
Also Jira projects are then assigned to the team.
Menu: Agile -> Team Desktop - Server
Remark:
- Nice overview
- Good way of creating sprints (use 'Add' button on right)
- Good Planning board, with nice working sub filters (Assignee, Sprint, Project Overview)
- Issue: when changing the 2nd filter 'Version', into something else, the 'Version'
dissapears, so you can never select it again as a filter. (Without leaving the Agile
interface first) - Good Task board
- Minor issue: the value of the 2nd filter (Sprint) is not the user friendly text
(at least it is different from the other time it is used)
Question:
- Is the idea behind adding sprint(s) that a team could create a period / time-frame of say 2 months
in which they do 4 sprints of each 2 weeks? - adding 4x a spring, where the parent is the above create period (like an 'alpha release')
Improvement:
- It would be nice to see in the 'Chart Baord' the daily realized burndown. We have
quite some times, where the initial estimate is incorrect, or several hotter items
are moved in. Officially also items should go out... But that is never done, so
sprints graphs look strange, and it is hard to see the work we did do! Also this
would show better on which days more is done (some days we have several meetings,
not everyone is working hole weeks, or vacations).
In graph optional: 'Establized Daily Burndown Rate' - Would it be possible to have a per person calendar, in which people who do not work
5 x 8, can correct their working schedule.
What you need to do for running this GreenHopper plugin:
- install / set up a Jira 4.2 installation
- unzip tar.gz
- set jira_home in $JIRA_APPLICATION/
- start Jira (I used standalone mode)
- $JIRA_APPLICATION/bin/startup.sh
So it will create the structure, where the plug-in needs to be copied in
During first startup also go to http://localhost:8080 and set up Jira (License etc) - stop Jira
- $JIRA_APPLICATION/bin/shutdown.sh
- copy the plugin into the $JIRA_HOME/plugins/installed-plugins/
See OSGi based plugin: http://confluence.atlassian.com/display/JIRA/Managing+JIRA%27s+Plugins#ManagingJIRA%27sPlugins-ManagingPluginsManually - finally start Jira again
- $JIRA_APPLICATION/bin/startup.sh
No idea what is wrong (or what I do wrong), but when starting Jira v4.2, I always see this on the console:
MMMMMMMMMM .,MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMM. OMM. ~MM.. MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMDMMZ7MMMMMMMMN7DMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMDMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMZ IMMM ..MMN= ,8MO 8 IN +DM8 ?MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMM ..OI . 8I...MMMO 8 IN M7 ,MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMMN, . +MMMMMO 8 IN =O M~ ~..$MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMMMM~... +MMMMMMO 8 IN . . IN I..+MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMMMMMI . OMMMMMMMO 8 IN := ,O =8 MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMMMD ... .MMMMMMO 8 IN =O + .MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMMM, =N. .7MMMM~. 8 IN =O :. =M. .MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMM, . MMD. .+MMM= :$M IN =O , IM: .MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM ____ _ _ _ | _ \ | | (_) | | | |_) | ___ ___ __ _ _ _ ___ ___ _ _ ___ _ _ | |__ __ ___ _____ _ ___ ___ _ _ ___ ___| | | _ | / _ \/ __/ _` | | | / __|/ _ \ | | | |/ _ \| | | | | '_ \ / _` \ \ / / _ \ | / __/ __| | | |/ _ \/ __| | | |_) | __/ (_| (_| | |_| \__ \ __/ | |_| | (_) | |_| | | | | | (_| |\ V / __/ | \__ \__ \ |_| | __/\__ \_| |____/ \___|\___\__,_|\__,_|___/\___| \__, |\___/ \__,_| |_| |_|\__,_| \_/ \___| |_|___/___/\__,_|\___||___(_) __/ | |___/ JIRA Standalone Edition Version : 4.2 Detecting JVM PermGen support... PermGen switch is supported. Setting to 256m If you encounter issues starting or stopping JIRA Standalone Edition, please see the Troubleshooting guide at http://confluence.atlassian.com/display/JIRA/Installation+Troubleshooting+Guide Using CATALINA_BASE: /home/tverhagen/data/jira_4.2 Using CATALINA_HOME: /home/tverhagen/data/jira_4.2 Using CATALINA_TMPDIR: /home/tverhagen/data/jira_4.2/temp Using JRE_HOME: /usr
- When entering one of the Administrator -> GreenHopper menus, you'll be asked to install a GreenHopper license.
After gettting one, from teh atlassian site, it can take a few minutes, before it will be accepted, once copied
in you Jira installation (try a few times).
I can't create a sprint with the same name again. Bug or feature? If I remove a sprint I can't create a sprint with the same name again.
Thanks for your great work!
In Planningboard: I create some sprints like "2010 Week 43" and "2010 Week 44". IMO he lists the sprints in wrong order and ignore the start date?
Please note that while this issue has been resolved in 5.6.0 the status will let you know whether it has been Fixed, Answered, Obsolete or Won't Fix.