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:
  • _is_child
  • _is_backlog
• 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:

• Import XML
• Display Homepage (w/o burndown yet), see mock-up or codepen
• Display Content page, see mock-up

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
  • Homepage
  • Content view
• 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.