Stories

Assumptions

• A physical Kanban board exists
• The rules of the Kanban board are not known by the Kanban Data Tracker

Guiding principles

• It should always be possible to manually add and edit any of the data
• The team's rules and processes do not need to be known and are not enforced by the Kanban Data Tracker
• Data collection should be easy and fast

Persona

John is a software developer on a team which uses Kanban to manage their daily work and development process. John wants to easily collect and analyze data from the Kanban board so that the team can periodically (and regularly) tweak their process to achieve greater efficiency, productivity, quality, and effectiveness (in other words, to get better).

Entities

• Swim lanes
  • unique id
  • name
• Queues
  • unique id
  • name
• Tasks (stories, stickies, etc)
  • unique id
  • name
  • size
  • status
  • arbitrary text
• Work In Progress Limits (WIP Limits)
  • WIP - the number of in-progress tasks
  • One or more swim lanes can share a common WIP
  • One or more queues can share a common WIP
• Events
  • date/timestamp
  • name
  • type
  • notes
  • Some events are common, and some are uncommon. Common events should not require a lot of user intervention, while uncommon events may need some explanation from the user
• Task Statuses
  • User-definable
  • Base Statuses (all user defined statuses are one of the following three base statues):
    • Not Started
    • In Progress (started)
    • Finished
• Iteration
  • A period of time in which data is compared
  • name
  • start date
  • end date

Stories

Admin

• John can create a new swim lane
• John can create a new queue
• John can edit an existing swim lane
• John can edit an existing queue
• John can assign a WIP to one or more queues
• John can assign a WIP to one or more swim lanes
• John can designate a default status for queue (when tasks are moved into the queue, they are assigned the queues default status).
• John can define a new task
• John can manually assign a unique id to each task, swim lane, or queue
• John can ask the system to assign a unique id to each task, swim lane, or queue
• John can tell the system the order swim lanes should be displayed
• John can tell the system the order queues should be displayed
• John can define the default length of an iteration
• John can define the starting date of the first iteration
• Based on the default length and starting date of the first iteration, the system will automatically create future iterations
• John can change the starting and ending date of any individual iteration
• John can assign names to each iteration
• The system can generate a default name for each iteration
• John can define the task statuses
• Any changes John makes to a queue, swim lane, WIP, or iteration is logged
• John can provide a reason why a swim lane, queue, iteration, or WIP was changed

Data Collection

• John can tell the system what tasks are in each swim lane and queue. This is known as entering a "snapshot" of the board. When John does this, the system will:
  • Record the snapshot
  • Record the date a task appeared on the board
  • Record the data a task disappeared from the board
  • Record the date each task moved from one queue to another queue
  • Record a date each task moved from one swim lane to another swim lane
  • Record the number of tasks in each swim lane
  • Record the number of tasks in each queue
  • Record the number of tasks in each swim lane & queue
• John can record a snapshot on a frequency of his choosing (usually daily)
• John can record a snapshot for the future (John can record a snapshot for tomorrow)
• When a story moves to a new queue, its status automatically changes to the default status of that queue
• John can explicitly record the status of a task when recording a snapshot
  • The status John records overrides the default status that may have been assigned
• John can enter a new task, swim lane, or queue while collecting a board snapshot
• John can optionally store a picture of the board with a snapshot
• John can view any of the data previously collected
• John can edit any of the data previously collected

Reporting

• John can use a predefined set of reports
  • Throughput by iteration
  • Cumulative Flow Diagram
  • Cycle time by size
  • Time spent in a specific queue
  • Time spent in a specific status
  • more??
• John can generate and review reports at any time
• John can create new reports

Integration

• John can, but does not have to, integrate the Kanban Data Tracker with a full-fledged task management system like Pivitol
• John can develop a plugin to integrate with a new task management system
• An integrated task management system can be updated when a board snapshot is recorded ** The current state of tasks defined in the task management system will be updated based on the snapshot
• John can use the data in a task management system to define swim lanes, queues, tasks, task statuses, and iterations