LACE (CCSQ Lean Agile Center of Excellence)

Page tree

Program

Work in progress — Tantus HCD


Background

Work in progress — This is the background. Why is the program reaching out for assistance?


Workflow Analysis

The HCD Team work is managed under a Jira project. Nine (9) boards are created to support their work. The goal of this section is to analyze the active board for the daily work.

  • The HCD Daily Scrum is used by the team to manage their daily work. The Board is composed of 6 columns representing the steps a work item can follow from start to completion: To Do, Started, Today, Blocked, Waiting, and Done. The Board is also composed of 7 lines also known as Swimlanes that represent the team members and active participants to who the work items can be assigned: Amy, Brandy, Brian, Chelsea, Howard, Meaghan, and Rob.    
    • At the time of our analysis on August 25th, the workflow shows a total of 56 work items spread throughout the board as follows: To Do (9), Started (11), Today (14), Blocked (0), Waiting (10), and Done (12). Also, the board reveals that the 56 work items are assigned to the team members and participants as follows: Amy (6), Brandy (1), Brian (12), Chelsea (11), Howard (8), Meaghan (13), and Rob (5).
    • Observation 1: There is an interrogation about the purpose and the benefit of the "Started" vs "Today" and "Blocked" vs "Waiting". Someone may think that the work items under "Today" should be part of the "Started" column, and also work items under "Waiting" should be part of "Blocked" since waiting is a type of blocker. Furthermore, the work items are grouped under various predefined epics such as Training, HCD Community and CoP, Thought Leadership, Team Consulting, PRA, CSAT, ... It would be interesting to understand the nature of their work items and to review what processes can best fit and support the management of their work.     
    • Observation 2: The HCD team is working on a 4-week iteration cadence, roughly 20 business days if there's no holiday. 7 business days before the end of the iteration, we can notice that 35 work items are in progress, which represents about 65% of the work planned for the iteration. We can notice that the amount of work in progress at a time is high. Also, there are no visible work-in-progress (WIP) limits per column or per team member/participant. It would be interesting to understand the team capacity, capacity allocation, and determine the right WIP limits for each of the columns in the process when relevant.     
    • The stories often include a review or collaboration task. Collaboration is inherent in team delivery, and review is part of the team's process. That should be a column on the kanban and a status

Requirements Analysis

The HCD backlog is composed of 2 main types of requirements: Features and User stories. The Features are larger requirements and can be decomposed into smaller requirements called user stories. This section aims to analyze the features and stories.

  1. Features:
    • Features are generally linked to Epics and have a version assigned
    • A standard format for features is needed. Some features have a lot of details. However, the purpose and benefits of the feature can get lost in the long narrative. It could help to capture the essence of the feature (benefit hypothesis and success measure) in the description, then add a "note" section for more details. A good example of features that need better structured are IPHCD-2776, IPHCD-2776, IPHCD-2771, IPHCD-2775, IPHCD-2773
    • The statement of the Benefit Hypothesis can be improved. Instead of authoring the feature in the user story format, we recommend the following Benefit Hypothesis format: "We believe that by doing XXX action/activity/function, we will achieve YYY benefit". This helps to approach the feature as a hypothesis that can be TRUE or FALSE after implementation/experimentation (ex: IPHCD-2776, IPHCD-2776, IPHCD-2771, IPHCD-2775, IPHCD-2773)
    • Success measure instead of acceptance criteria: First the acceptance criteria is a To Do list or list of tasks instead of being binary criteria that can be validated (ex: IPHCD-2776, IPHCD-2776, IPHCD-2771, IPHCD-2775, IPHCD-2773 )
    • The title of the feature is vague. It is should summarize the hypothesis that is put to test (ex: IPHCD-2776)
  2. User Stories:
    • The user stories are large and comprised of many independent and dependent pieces of value
    • The active sprint shows that each user story is linked to a feature and most of them are assigned to a version
    • Each story is also assigned to a team member and is estimated in story point. There are stories with the size "0". It would be important to understand why or the rationale behind it
    • Acceptance criteria read as tasks and include inter-team collaboration (IPHCD-2855)
    • Notes and tasks are referenced that are not included as a user story (IPHCD-2855)
    • Value statements missing for some stories (IPHCD-2808)
    • Value statements juxtapose internal/external users and internal/external value (IPHCD-2855)
    • Acceptance criteria are broad and not binary (IPHCD-2791)
    • Story titles are vague at times. This could be due to:
      • The LACE not knowing your work well
      • The scope of the stories is too large
  • No labels