Executive Overview
Make AgileDasbhoard/Scrum more flexible.
Principles
The objective of Scrum v2 is to:
- Allow more flexible organizations (do not mandate every body to have releases splitted in sprints)
- Remove magic from Agile Dashboard (rules are clear, easy to understand for end users and easy to implement for developers)
- Be the base for new features (like team management)
Rules
- There are 2 kind of elements
- Backlog items (eg epics, stories, tasks)
- Milestones (eg releases, products, iterations)
- To use one artifact in Scrum, its tracker must be declared as either Backlog Item or Milestone
- eg. given previous organization, if I want to deal with bugs, I need to declare Bug tracker as Backlog item first.
- Scrum relies on Artifact Links types:
- Scrum put some constraints on links usage
- _is_child can only be defined between artifact of same "family" (eg. I cannot have an epic child of release, but I can have an epic child of task)
- _is_backlog can only be used between one Milestone and Backlog Items
- One "Backlog item" can only be _is_backlog of one Milestone
- Given "Epic A" _is_backlog of "Release 1.0"
- When I put "Epic A" _is_backlog of "Sprint 40", it's removed from "Release 1.0" backlog
- One Milestone backlog is made of all its _is_backlog links plus all _is_backlog of its children
- Given previous example,
- "Epic A" is still displayed in the backlog of Release 1.0
- For Backlog Items, as long as one of my children is "_is_backlog" of a milestone, I can no longer be removed of "_is_backlog"
- Given Epic A with Story A.A child
- And Release 1.0 with Iteration 40 and Iteration 41 as children
- And Epic A is in Release 1.0 backlog
- And Story A.A in Iteration 40 backlog
- Then Epic A cannot be _is_backlog of neither Iteration 40 nor 41
- And Epic A cannot be removed _is_backlog of Release 1.0
- Artifacts are explicitly marked ask "used in Scrum"
- The backlog is no longer automatically populated from a tracker
- A "root Backlog Item" is a backlog item without parent
- A "root Milestone" is a milestone without parent
Steps
Step 1: demonstrate flexibility of data structure.
Functional:
Technical
- Introduce "_is_backlog" type
- Manage XML import
- Format
- Enforce consistency rules
- Flag artifacts "used in scrum"
- Identify trackers "Backlog items" or "Milestones"
- New angular app with
- REST routes
- Homepage
- GET|OPTIONS /projects/:id/milestones?query=current|past|next
- GET|OPTIONS /milestones/:id/milestones
- Content view
- GET|OPTIONS /milestones/:id
- GET|OPTIONS /milestones/:id/backlog
- GET|OPTIONS /backlog/:id
- GET|OPTIONS /backlog/:id/children
Step 2: demonstrate how to plan
- Update Planning view to show the new data structure
- Requires to update the way the data are queried
- Be able to create elements
- Be able to plan items in milestones
- Requires the enforcement of "Consistency rules"
- Introduce the administration panel to define
- Milestone types
- Backlog item types
At this step, it's possible to interact with the data:
- create new root milestones & root backlog items
- plan backlog items into milestones
- break milestones in sub milestones
- break backlog items in sub itmes
Still not usable for new projects "from UI" (still reserved to projects created from XML import).
Step 3: cardwall view and burndown
- Update cardwall view to use new data structure
- Update burndown to use new data stucture (burndown is rendered in content view)
- Update tracker triggers to be able to use links
At this step, people coming from XML import have something "feature complete"
Step 4: migration
- Existing agile dashboard users are moved to scrum
Technical details
- New app & plugin scrum
- Single angluar application that contains home page, content and planning
- Cardwall => need to find a solution.