Risk Handling - Scrum of Scrum

Introduction

Scrum is a framework to abridge the gap between UNKNOWN (Risk & Assumptions) and KNOWN (Clear Requirements).

?As a Scrum Master, our foremost task is to move UNKNOWN to KNOWN through Empiricism (Transparency, Inspection & Adaptation) by applying LEAN (Remove waste, Remove Duplicate, Add Value) approach Iteratively.

?Implementation of iterative empiricism & Lean Thinking is only possible, if the Scrum Team takes the ownership of work logs (Features, Product Structure, Defects, Bugs, Risks, Impediments). Each Scrum Team ownership comes with a backlog of Management support that may be in the form of Scrum of Scrum Team or even higher than this.

The first stage to normalize worklogs is planning.

Planning

for normalizing the work logs are ascribed to;

• design sprint
• pre-planning & development sprint
• Release Integration Planning
• UAT & release sprint

at each of the sprint classification the work logs are refined further for estimations near to actuals / realizations.

design sprint (phases)

• Understand,
• Define,
• Sketch,
• Decide,
• Prototype, and
• Validate.

Outcome of these phases are

• Identified personas
• identifying unknown shady areas
• journey mapping
• increased usability
• approved figma designs
• feature listing
• epic classification
• epic estimations
• At the end of Design Sprint, we ensure that worklogs (EPICS) meet their DoR. ?

Pre-Planning and Development Sprint

Pre-planning or Spike is usually the Sprint 0 where

• Identified & listed Epics reconciling with DoR are discussed by Product Team with Engineering Squad
• For these epics Product Owner starts writing Functional Worklogs while Development Team starts writing Technical Worklogs (Task)
• Impediments at Functional worklogs are identified and attributed to appropriate person.
• Similarly, dependencies are identified linked to functional worklog as either “blocked by” or “relates to” as deemed appropriate.
• “Blocked” functional worklogs are estimated 8 Story points
• “Relates to” functional worklogs are estimated 5 Story points
• SM facilitates the engineering Squad to get clarity and negotiate worklogs so that their SP can be reduced from 8 & 5 to 3 or 2 or 1 or 0. However, the accountability rests on the Engineering Squads & not the SM
• Story Point (SP), Original Estimate (Dev + QA Time), Assignee, each assignee first worklog Start & End Date, Fix Version, Labels estimations for prioritized epic worklogs with clarity is started and planned for next 2 sprint.
• These newly estimated worklogs are prioritized within sprint backlog based on WSJF or other prioritization techniques the team chooses.
• The Development Team itself assigns / reassigns these worklogs at pre-planning as well as during development sprint

Release Integration Planning (RIP).

At this stage

• All the engineering squad (PO + SM + Dev [2 People] + Other Team Member [1 person each team]) will gather around and call out their Blockers and as per RIP empiricism with lean thinking plan their execution
• Similarly, RIP will also call out all dependencies of each Squad & update with empiricism & lean approach update Release Plan accordingly.
• IP will reaffirm through a Charter the Release Scope for each SQUAD, SoS members their responsibilities [RACI] their metrics & measures to ensure smooth Release Roadmap?

Development Sprint

is usually when the

• Planned Sprint Backlog is worked upon & same is reflected in work logs through commenting & linking.
• At each daily scrum engineering squads using their respective dashboard share their blockers, priority logs, WIP (Work in Progress), time estimates (Dev & QA) against time spent at each DoD layer. Using lean approach apply empiricism to plan their daily execution.
• The scrum master facilitates the development team members by collaborating & negotiating their promised work logs.
• Scope change within the sprint is discussed with team & re-negotiated with stakeholder by product owner without compromising sprint goal
• Next 2 Sprints Planning events are worked upon. The work logs are further refined, groomed, estimated, assigned & planned through iterative approach like [first 20 minutes PO Grooms the worklogs], [Next 40 minutes Engineering Squad in 2-3 member groups discuss technical implementation]. On subsequent day SM sets up a Development Finalization Call for 60 minutes to finalize the technical implementation of initial 2 worklogs per assignee. Finally, a call to finalize estimations, assignment & other necessary updates.
• The SM facilitates blockers & dependencies handling while escalating new / delayed ones at SoS / RIP level and mark their update in Engineering Squad Release Plan as well as Integrated Release plan
• At the end of sprint Product Review is given by the team to Stakeholder
• Stakeholder Feedback (20% max) with sprint goal is taken at Product Review
• Sprint Retrospective is done with focus on next development sprint

Release / Shippable Iteration.

• After every 2 sprint there should be a 1 week Testing Iteration to ensure the product is tested at Integration level and P1/P2 regressions, escaped defects, bugs, security lapses, performance havocs are resolved.
• Similarly, during this the week next 2 sprints of a Release are also planned by Pre-planning & RIP RIP

Dor / DoD of Worklogs and the Sprint Execution

While User Stories are classified as MUST Have & Improvements as Good to Have, while Tasks are the technical constraints, dependencies, impediments or other worklogs that we must meet to ensure Functional Work logs (Stories & Improvements) can be completed as plans.

Hence each Task is linked to a Functional worklog by linking it in JIRA using “Relates To.”

Handling risks & impediments while keeping a good Morale Score requires Work logs to meet DoR & DoD before they become part of the Product Increment.

?

DoR (Definition of Ready)

The Definition of Ready (DoR) defines the ready state. In simple terms, an epic/user story needs to meet some criteria (or conditions) before it can be picked up for a release/sprint. The?DoR?collects all the conditions necessary for a user story/epic to be developed in the current sprint/release.

The?PO/PM is accountable and responsible for the DoR that must have all details required by the organization, and description of the epic/story in consultation with the team.

A typical DoR constitutes of;

• Add a description – Description
• Add an acceptance criterion like Either, Given-When-Then, or As a Role-What-Result.
• Prioritize the Epic/Story – (use prioritization techniques like WSJF (weighted shortest job first), Customer demand, Ranking, MoSCoW, Five Why’s, KANO, etc.)
• Assign a?high-level?Size for the Epic. (the context of size here is to give it a number (Fibonacci series), or t-shirt size (S, M, L, XL, XXL) and?not?estimated effort, time)
• What value is it adding to the product – Is it an organization initiative?
• What is the customer's perceived value? –?This information is important for the stakeholders and salespeople.

DoR - Epic

Detailed Appropriately: Dependencies are identified and no external dependencies would block the PBI (Product Backlog Item) from being completed. Details are sufficiently understood by the development team so it can make an informed decision as to whether it can complete the PBI.

Emergent: The feature should not be static. As the project progresses more information (description/user stories) can be added.

Estimable: The items at the top of the backlog have more accurate estimates. The lower priority items are estimated at a high level and can be re-estimated as the team gets more information.

Prioritized: Business value is clearly articulated. ?Performance criteria, if any, are defined and testable.

DoR – User Story amp; Improvements

Independent: The work item should be independent (self-contained and possible to bring it to progress without any dependency on other work items or external resources).

Negotiable: Should have enough room for discussion regarding its optimal implementation

Valuable: What value it provides to the user, should be clear.

Estimated: In story points (note the story points is a unit-less unit, i.e., it may not mean 1 point = 1 day, or a couple of hours).

Note: Estimation – Not all XXL stories will have higher story points, and not all S, M ? stories will have less story points. It is based on the level of Complexity, Uncertainty, Dependency

Small: The PBI (Product backlog item) must be estimated and small enough to be completed in one sprint.

Note:?Slicing – there are various techniques – Vertical, SPIDR (Spike, Path, Interface, Data, Rules) – whichever applies to the story can be used.

Testable: Acceptance criteria are clear and testable.

?

DoR – Technical Works (like Task)

• Task adds a value & is not a duplicate
• Task is clearly understood & well defined
• Task is estimated?by development team
• Task is achievable within a sprint
• Task is independent & Testable
• Task?dependencies?have been identified

ESTIMATIONS

Story points (sp)

It is a worklog health measure for Engineering Squad based on FUNCTIONAL, TECHNICAL clarity and work log estimated DURATION. Development Team can according to its complexity and length assign story points as;        

Other Estimations

They include

• Dev Estimate
• QA Estimate
• Original Estimate
• Labels
• Fixversion
• Start Date
• Finish Date
• Assignee
• Tested By

SoS Handling

A look at Story Point suggests that it is used by SoS (Scrum of Scrum) Team to resolve dependencies and prioritize obscurities.

It does not imply that a work log of Story Point 8 or 5 cannot be taken into sprint. It only suggests there are impediments / dependencies that need to be resolved before their ETC (Expected Time of Completion). Violating the ETC deadline means a risk has occurred and now is an ISSUE. Hence, the SoS Team would now be responsible for suggesting these RISKS/ISSUES be handled through Risk handling measures before they seriously impact Release. The focus is to transform these to SIMPLE work logs that can be taken in the sprint. If SoS Team fails to get these ISSUE resolved, then the items cannot be taken into release.

SoS Team needs to have these logs visible into their own SCRUM Board with columns defining the risks/issue linear dependency stages before these risks turns into Issue and eventually causes delay in Release or even worse impacting dropping of a feature due to time constraints.

PLEASE NOTE: THESE ARE SOS BOARD STATUSES AND SHOULD NOT BE JUMBLED UP WITH LOG STATUSES.

SoS Board Statuses are free-flowing and can be moved from all statuses to all statuses except there is no movement from DONE to any other SoS status. This is because SoS needs to re-evaluate the Re-Open case and devise new dependent logs with revised method that complies with Lean & Empiricism.

?

Risk / Issue handling of SoS Board

Risk is Listed (Blocked)

The Development Team, when confronted with an impediment that is impeding their planned work, must link the blocked work log and commenting their expectations on work log.

Step 1

This is the Planned Start & Finish dates that has been communicated to all SoS members. The planned start date unequivocally should be on the subsequent workday of its dependent planned blocker finish date.

Any delay in its blocker finish date can impact delay in delivering the related feature or adversely even impact release items being shelved for later release.

?Step 2

Link the work logs that could delay delivery of SoS-1 work log by linking it to its blocker worklogs. If a worklog does not exist like Theme changes can only be communicated once the “Design call for theme changes happens,” in such a scenario a work log (SoS-4) should be created and linked as BLOCKED BY in SoS-1 worklog.

This step is also termed as “Risk Listed” and it automatically generates “Risk Raised” (its blocker work logs are moved to “Risk Raised”).

Once the “Risk Raised” happens the impacted Scrum Team / SoS needs to reiterate the planned expectations, so that any deviation in deliveries be handled promptly and prevented be acted upon before realization of “Risk” that is it reaches to “RIP.”

Step 3

As soon as the SoS Team initiates an action by commenting on the dependent work log(s), re-affirming its assignee with agreement to its due date the work log would move to “RIP” state indicating the action has been requested and expected to be initiated by the assignee to resolve its dependency.?

Step 4

Once the Finish Date in this case (15-Feb-2024) reaches / passes the present (now) date the Risk occurs and becomes Issue (“ISSUE CREATED”). Once the issue is created it is highlighted to SoS team once more to promptly highlight & resolve it before it impacts the release scope, time, quality, resources, budget, etc. are impacted adversely.

Step 5

• Once the Risk / Issue has been resolved/removed the worklog moves to Done state. Now this work log is available for Development and can be planned & estimated by the Development Team to be included in the sprint.
• There are number of attributes that these SoS logs should have like;
• Start & Finish dates (as per planned SLA)
• In addition to Assignee there should be Responsible, Accountable, Consulted & Informed attributes
• Risk Identification By & Date, Risk Raised By & Date, Risk Action By & Date, Risk Resolved By & Date. (RACI)
• Requested Risk Action that should not be mixed with Comments on logs

These Custom Fields need to be associated with SoS Screen(s) so that these attributes are only visible to SoS board and do not impact other screens as mentioned here.

?Output of SoS Board

Risk Register

The automated report that would be available on Dashboard and is easily accessible to SoS Members with automated emails functionality whenever there is an update on the logs.

Based on the data captured on SoS Board we can have a Risk Register like Risk_Tracking_Template_

RACI

Based on the data captured on SoS Board we can have a RACI like

Sprint Metrics

BURNDOWN / BURNUP

Burndown / up statistics ESTIMATIONS can either be computed on Story Points, Original Time Estimate or Issue Count

Story Point Estimation

is used for Capacity Planning. Usually used when we are designing / planning Release Board. Here based on team capacity to handle Story Points we could estimate how many features a team could deliver with the limited visibility. For example;

Original Time Estimation

is mostly used for boards that are based on KANBAN where we are more concerned with Lead Time / Cycle Time / Throughput Time. Here Cumulative Flow Diagram as a metric is advised.

This estimation method is ideally suited with teams like Technical Support where metrics like

Lead Time (From Start to Complete Duration)

Higher throughput is achieved when the work is intricately planned, assigned, and estimated with known factors and outputs. Henceforth, KANBAN is more of a preferred method that deals with “Time Estimation” to increase throughput.

For instance, in Kanban we analyze our Lead Time Variances and figure out what can be done to maintain least lead time like What practices we have dropped from “2018-10-01” when we reached “2018-10-08”, Why we dropped them, how we can add measures to ensure our throughput is steadily rising. The Technical Support / Accident Handling Team needs no grooming, they are experts in their domains and rarely escalate issues to engineering because of their techno-functional depth.

Issue Count Estimation

is applied on Squad’s past 3-5 sprints average of committed work logs to predict as per Squad’s Velocity for feature deliverables with utmost ROI (Return on Investment).

For example, “Elite” Squad is delivered “X Feature” for Release N.N.0 with

X Feature Delivery Issue Count

With;

4 Developers

4 Developers X 80 Sprint Hours X 6 Sprints = 1920 logged Hours

Bug Time spent is 39% of 1920 Hours = 748 Hours

Product Structure Time is 14% of 1920 Hours = 269 Hours

Feature Time of a sprint is 47% of 1920 Hours = 902 Hours

In 6 Sprints “X” feature was delivered using 902 Hours

With an average Velocity in terms of SP; 1 SP 3 logs + 2 SP 4 logs + 3 SP 7 Logs + 5 SP 4 Logs +8 SP 1 Log it can be termed that the burndown capacity for a given sprint is this only any additional load given to the team means delay in Release Date.

With an average Velocity in terms of Issue count;

Team delivers 13 Bugs + 5 Improvements + 11 Stories + 5 Product Structure Logs

CONCLUSION

It is easier to estimate / predict in terms of issue count impact of adding/removing work log from a sprint and reviewing Burndown than estimating / predicting / predicting / predicting / predicting based on Story Points where the story needs to be groomed than estimated.

DASHBOARD

These are based on KPI / OKR. Once these KPI’s / OKR’s are finalized we can formulate the dashboard accordingly.?

An example Dashboard would be;

Provides a view for Scrum Team to Review their progress in terms of

Risky Logs.

Logs that have a Story Point >= 5 lie on the Critical Path. A delay in them means a definite Spill. Such log dependencies & clarity must be avoided before they are taken up by the Development Team.

In every “Daily Scrum” their progress is monitored & corrective action needs to be adopted by applying Lean thinking and using empiricism as a tool.

Priority Logs.

At least on Daily Scrum the team should discuss ways of focusing & resolving them on agreed SLA

Log Report

ensuring people have committed their hours on their respective current

Created vs Resolved Issue count

showing when & how many issue counts have been added to the sprint scope. This also shows teams collaboration & agility to respond to new requirements. However, a downside is that the team may be working on items that were not groomed / planned / risk identified hence may lead to overcommitting.

i)??????? Time in Status Report. It will show how much time a log has been in the same status thus enabling the team to focus on aging logs

i)??????? Sprint Burndown. This could be based on Story Point / Original Time Estimation / Issue Count. As mentioned, issue count should be used as a velocity burndown metrics because we can have buckets of log type

(Another Gadget would be aging report where original estimate | dev+qa estimate < timespent) using JQL Advance query like

“Squad [Dropdown]="IT Elites (FE/Unified UI)" and fixVersion = 5.1.0 and issuetype not in("Sub-Task","Subtask","Epic") and sprint not in (" veterans") and sprint in opensprints() and issueFunction in expression ("", "timespent + remainingestimate > originalestimate")?

However, Advance JQL is not enabled with my user, so it cannot show that report.

Performance (Individual / Sprint / Release)

Provides a view for Scrum of Scrum Team to

• Handle Issue/ Risk (Risk Register)
• Review Long lasting Risks with SLA’s & RACI (RACI with old risk list)
• Overall, Team Performances
• ?

Provides a view for Management to

• SQUADS Progress towards Release Goal (Burndown/up)
• Risk & RACI Reports
• Overall, Team Performances / Lags (Time spent ration on bugs, product structure, feature), Sprint Grooming Clarity in terms of 5 & 8 Story Points