Risk Handling - Scrum of Scrum
Shariq Saad
DigitalTransformation | ScrumMaster | SAFe Agilist | True Leader | JIRA Pro. Helping teams | organizations build Agility with Maturity | #CommittedToAgility
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;
at each of the sprint classification the work logs are refined further for estimations near to actuals / realizations.
design sprint (phases)
Outcome of these phases are
Pre-Planning and Development Sprint
Pre-planning or Spike is usually the Sprint 0 where
Release Integration Planning (RIP).
At this stage
Development Sprint
is usually when the
Release / Shippable Iteration.
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;
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)
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
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
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
Provides a view for Management to
Certified Scrum Master | Quality Assurance| Database Applications Development
11 个月Congrats, on polishing new research work for Risk Handling in Scrum! Awesome information and techniques you have discussed. Surly we can improve our productivity following the techniques and reduce Risk during the critical project implementation and client’s deliveries. Keep it up dear.
MERN Stack | Senior Software Engineer | Full Stack Developer | React | Node | Docker | AWS | Microservices | JavaScript | TypeScript | ES6+
11 个月Congrats on completing the course! Excited to see how we can apply these strategies in our projects.
Software Development Manager | Engineering Manager | Technical Project Manager | Driving Excellence in Project Delivery and Team Performance
12 个月Thanks for sharing an insightful article on Risk Handling on Scrum of Scrums provides practical strategies for managing complexities in large-scale Agile projects. It's very practical on implementing empiricism thus improving communication, and collaboration, offering actionable recommendations for mitigating risks effectively. A valuable resource for Agile practitioners navigating the challenges of scaling Scrum methodologies.