Problem/Solution Validation: How Teams Organize and Track Sprints and Releases
What’s this issue all about?
- There's been a request to allow issues to be associated to more than 1 milestone (https://gitlab.com/gitlab-org/gitlab-ee/issues/5135#note_195641872).
- This makes sense as teams want to track an issue against both an iteration/sprint and a broader release. In fact, I wish we could do that more easily at GitLab so we could efficiently have shorter iterations within a given release.
- It is clear to me we are lacking some core functionality around organizational constructs and tracking completion progress against them. The goal of this study is to surface the optimal way to move forward fixing these issues.
Who is the target user of the feature?
- Product Managers, EMs, Project Managers, Scrum Masters
What questions are you trying to answer?
- How do teams prefer to organize and break down their work and is it inline with how GitLab currently treats issues as the smallest increment, epics represent a collection of issues across projects on a group level, and milestones can be either project or group level and represent a collection of issues across multiple epics.
- How do teams prefer to track progress against their preferred method of organization?
Core questions
- Is associating an issue with multiple milestones the right solution to the core problem?
- Are we missing a different organizational construct in the product that is making users believe this is the right solution?
- What type of progress reporting do we need to be providing that we are not currently in order to provide users with the insights/feedback they need?
- How does the burndown chart need to evolve to support this? Do we need a different type of chart?
What hypotheses and/or assumptions do you have?
- It will be beneficial to associate an issue to multiple milestones.
- There is a disconnect between the usage of Epics and Milestones because we are not reporting on completion progress of epics in any form or fashion and they are currently not tied to milestones in any way.
What decisions will you make based on the research findings?
- Implement the solution that best aligns with solving the original problem in the most primitive way.
What's the latest milestone that the research will still be useful to you?
- 12.4
Methodology
- Reviewing prior research related to sprint planning and milestones. Review feedback gathered in https://gitlab.com/gitlab-org/gitlab-ee/issues/5135#note_195641872.
- User interviews with 5 GitLab users.
Progress
-
Reviewing prior research related to sprint planning and milestones. [Deadline: Mon Sept 23rd] -
Write interview guide. [Deadline: Mon Sept 23rd] -
Send out screener survey to segment of GitLab First Look [Deadline: Fri Sept 20th] -
Advertise screener survey to commenters in https://gitlab.com/gitlab-org/gitlab-ee/issues/5135#note_195641872 Extra time allotted due to time OOO
-
-
Schedule users for interviews. [Deadline: Fri Sept 27th] -
User 1 - Monday Sept 30 at 10:00am PST -
User 2 - Friday Oct 4th at 1pm PST - No show
-
-
Conduct interviews. [Deadline: TBD] -
Purchase Amazon gift cards. [Deadline: TBD] -
Analyze videos. [Deadline: TBD] -
Document findings within the UXR_Insights repository [Deadline: TBD] -
Schedule a wash-up meeting. [Deadline: Fri Oct 4th] -
Add the Epic link to the wash-up meeting calendar invitation. [Deadline: TBD] -
Record and facilitate the wash-up meeting. [Deadline: TBD] -
Add the next steps/recommendations as agreed upon in the wash-up meeting to the Epic description. [Deadline: Deadline: TBD]
-
-
Update the Research proposal issue. Link to the report. Unmark as confidential if applicable. Change status to done and close issue. [Deadline: TBD]
/cc @uhlexsis
Edited by Katherine Okpara