Wondershare EdrawMind
MindMap Gallery Delivery Specialist
- 25
Delivery Specialist
A delivery specialist is an individual or a professional who specializes in managing and coordinating the delivery of goods or services to customers or clients. They typically work in industries such as logistics, e-commerce, retail, or food services, where timely and efficient delivery is crucial.
Edited at 2022-06-29 19:57:03
- Recommended to you
- Outline
Delivery Specialist
Core Behaviors [5 - 16,7%]
Constant Business Alignment
Business Vision
The Delivery Specialist should:
Turn the vision into a workable solution architecture
Deliver a solution that addresses the business vision
Analysis
The Delivery Specialist should:
Map out initial user stories and business vision to the solution architecture
Collect user stories and cross check with stakeholders
Propose innovative solutions and processes to deliver the maximum business value
Solution Architecture
The Delivery Specialist should:
Understand the solution architecture
Discuss and agree on the functional architecture with the Tech Lead
Map new User Stories into the existing architecture
Solution
The Delivery Specialist should:
Understand and explain how the business use cases map to the solution
Translate technical and architectural complexities to stakeholders
Negotiate Iteration backlog
Backlog Settlement
Summary
Understand and define business vision
Analyze and transform it into a workable solution
Create the solution architecture
Building the solution
Be the user
Business Need
The Delivery Specialist should:
Understand the business needs that guide the project
Understand the conditions under which the project was approved
Sub Topic
Business Case
Understand how the business case addresses the business need(s)
The Delivery Specialist should:
Identify the critical success factors
Map how the business case addresses each business need
Fully understand the business case
Drive important decisions in the Project alignment with success factors
Build Solution
Share solution architecture created by the team
The Delivery Specialist should:
Keep stakeholders and team aligned with the business case
Act as a methodology coach
Deployment
Guarantee the solution will provide the expected benefits to the end-user
The Delivery Specialist should:
Define a rollout plan
Identify and manage external dependencies
Always keep an eye on the production rollout
Providing Value
Providing value is not about building features
It is about delivering features that:
Meet the defined business needs
Are aligned with the project's business case
Summary
Understand business need(s)
Align with project's business case
Build a solution that meet the defined business need(s)
Deploy it maximizing business goals
Communication Hub
Being the Communication Hub is making sure the team and stakeholders stay connected and aligned throughout the project.
Project Team
The Delivery Specialist should:
Ensure the entire team stays connected throughout the project
Know the project team and provide the right level of information
Goals and Roles
Knows the entire blended project team and roles
The Delivery Specialist should:
Identify stakeholders and map their roles in the project
Identify stakeholders’ interests in the project
Avoid blind spots, conflicts of interest, manage risk
Channels
Provide a clear project vision and alignment
The Delivery Specialist should:
Establish the communication channels and paths required for smooth project execution
Identify who should talk with whom
Facilitate
Facilitate Communication
The Delivery Specialist should:
Keep communication focused
Ensure communication supports project goals
Eliminate communication bottlenecks
Summary
Ensure project team stays connect
Understand each team member role and goals
Establish a communication channel
Facilitate communication at all times!
Organization Awareness
Gols
Identify and Understand Goals
Identify Customer organization´s goals with the project
Identify Customer organization´s overall goals
Identify Each Person/Depto interest and participation on the project
Positioning
Position in the customer
Decide their positioning in the organization
Understand how the organization sees the team
If desired, define a path to improve positioning
Perseverance
Maintain selected positioning and alignment throughout time
Always be on the lookout for changes that may pose as opportunities or threats
Project Sucess
At OutSystems, we only consider a project successful if it goes live and shows high user adoption.
Summary
Understand Customer Organization
Identify Goals
Adopt a position within the company
Persevere and Maintain Alignment
Project Steering
Ensures the delivery of a system or product that addresses a real business problem, or need, and is easy to learn and use.
Plan
The Delivery Specialist should:
Understand customer’s expectations, motivations, and timelines
Plan each delivery accordingly
Communicate and Settle
Constantly communicate with Business and settle on alternative options, when things change
The Delivery Specialist should:
Understand business motivations
Manage customer expectations
Define a communication plan
Keep the customer in the decision loop at all times
Control
Control the key vectors of the project
The Delivery Specialist should:
Assess risks and act on them
Keep stakeholders and team focused on business value
Monitor project budget and deliverables
Negotiate
Ensure the project stays within the scope, budget and timebox
The Delivery Specialist should:
Negotiate new requirements and changes
Act as a problem solver
Say “no” and explain “why” when project goals are compromised
Seek to get the best out of every presented situation
Summary
Plan
Communicate and Settle
Control
Negotiate
Deliver with focus on what business users really need!
Sub Topic
Delivering at the speed of outsystems [5 - 16,7%]
What Is Different From Basic Scrum?
Modifications
Team roles and responsibilities
Employing other variations of Agile that can be better suited for a particular project
Adaptations
Driven by the need to avoid risks and delays
Risks and delays are detrimental to speed when working with OutSystems
Methodology
Introducing Agile components
Document requirements as persona based user stories
Implement solid user story standards and quality metrics
Hold periodic demos and deliver completed features for feedback
Continuous participation from the Business Team
Project Governance
Governance effectivenessEssential when working with OutSystems
Speed of developmentA team can go into the wrong direction just as fast as into the right one
Standards and governance must be solid for certain key areas
User Story and Requirements Quality
Risk Management
Estimation and Capacity planning
Issue Management and Resolution
Go-Live Planning
Agile Maturity/Coach
Agile CoachHelp to establish the right Agile framework and learn how to adapt over time
Include the Business team to ensure maximum participation and value realization
Mature Agile organizations develop the skills to coach and adapt internally
People
ROLES: Well-defined roles and responsibilities
BACKLOG: Right roles allocated at the appropriate level
STAKEHOLDERS: Available to make decisions and remove roadblocks
MINDSET: Strong, collaborative and focused on continuous improvement
Team Composition
The overall composition and size of the team is determined by
Project complexity
Timeline
Size
OutSystems projects usually have smaller technical teams
Smaller projects may have one person taking on several roles
Project Manager, Business Analyst, QA Lead and Scrum Master
Larger projects will have different people take on these responsibilities
To scale to larger or several developer teams
Often add a program manager or architect
Balance the depth of requirements against the speed with which they can be implemented
Stakeholders
Project stakeholders should be available to the project team at a rate that:
Avoids wait times and delays
Is adequate for the strategic value of the project
Important stakeholders:
Project Sponsor
Key Business Users
Product Owner
Other IT roles
Project Team Recommendations
An OutSystems development Team is usually smaller than a traditional one
A team of 2 developers with a Tech Lead is ideal for small to medium projects
The Tech Lead defines and ensures the quality of the delivered solution
Larger projects can establish parallel teams to work on different features
The QA team should be involved in the project from the beginning
Ensure quality early in the development process
Avoid a large backlog of defects at the end of the project
Project Team Roles
PROJECT MANAGER: Timeline, budget and delivery scope. Ensures the backlog is ready and deep enough
PRODUCT OWNER: Bridges the distance to business users during various ceremonies
SCRUM MASTER: Keeps ceremonies on track and assists with resolving roadblocks as quickly as possible
BUSINESS ANALYST: Quality of the user stories and performs the first round of testing
ARCHITECT: Designs the foundation of the solution. Also oversees and enforces best practices
UX/UI: Builds a strong UX/UI foundation. Assists with user testing and supports incremental design needs
FRONT END: Achieves a competitive look and feel required. Typically supports multiple projects.
SPECIALIZED ROLES: Platform Ops & DevOps
Mindset
Strong collaboration among project team members
Easily adapt to change fostered by stakeholders feedback
Continuous improvement and learning
Pride of ownership for contributing to delivering value
Alighment
Clear Vision
Work faster
Autonomy
Align scope priorities
Collaboration
Teamwork
Stakeholder Alignment
Alignment on vision, strategy, value definition and timeline is a catalyst for:
Fast prioritization of requirements
Issue resolution
Avoiding refactoring
Establish a proper communication plan and set clear guidelines for sharing information with stakeholders
Business Access
A direct contact line with the business and end-usersdeepens the Development Teams’ business context
Timely and iterative feedback and direction from the business team
Keeps the project moving in the right direction
Prevents working on the wrong requirements
Avoids decision making delays
Requires continuous engagement by the business
Faster and higher value perception
Higher adoption of the product
Product Ownership
Every project must have an authority that owns product’s definition and direction
Excellent business context and have a direct line to business sponsors and key users
Maintains and works toward acohesive vision
Avoids work delays and other inefficiencies
Quickly solve requirements questions and disagreements
Prioritize User Stories and defect resolution
Support and expedite risk mitigation plans
Backlog
User Stories with a level of detail that is well adapted to the needs of the team.Foundation for building a feature correctly.Supported by a team agreement on a solid Definition of Ready.
User Stories
Well-defined User Stories:
Avoids unnecessary rework
Improves quality
Improves speed
Mature agile teams may require less details in user stories
The notation of user stories should be in line with Quality Requirements
Facilitate and speed up the QA team testing process
Enable faster delivery and higher quality stories
Depth
Two sprints worth of backlog should be ready at any given time
Requires a good Definition of Ready from the beginning
It is very difficult to catch up once the backlog falls behind
OutSystems’ development speed can be surprising!
Agreed prioritization of the User Stories in the backlog allows to
Keep up the pace
Make smooth adjustments
Have IT and Business responding faster toaccelerating or shifting market demands
Workflow
A well maintained backlog:
Is the backbone of an Agile project
Supports end-user needs and perspective
Generates a better product fit
The entire project team and stakeholders should know and adhere to the stages of the workflow, and their ownership and responsibilities:
Inception
Shaping
Development
Testing
Acceptance
Closure
Continuous Improvement
Business Feedback
Regular product demos and frequent releases are essential to get continuous feedback
Ensures the development speed focuses on the most valuable business needs
Enables business users to accept the solution as the project evolves
Avoids surprises and delays during the final release testing
Speeds up the value realization and increases adoption of the solution
The feedback stream should be extended to when the product is already in Production
It fosters a closer IT/Business partnership
Generates high-value ideas from the product’s daily usage.
Frequent Releases
Drives the attention to build the product based on what is more important to the users, which will make them get value early
Encourages early feedback and continuous alignment to the most urgent business needs
Builds the discipline needed, and provides the opportunity, to react faster to market demands
Retrospectives
Teams can take improvement actions based on a regular analysis of important aspects:
Team dynamics
Effectiveness of ceremonies
Metrics
Methods
Processes
Retrospectives at the end of projects provide benefits to subsequent projects or releases
Post-sprint retrospectives should be part of the delivery process, to make them more effective
Together they optimize the value that comes from working with OutSystems
Quality
A quality plan must define the testing strategy and execution model, the tracked metrics and the desirable quality targets
Quality Plan
Establish the quality requirements
Set expectations for the acceptable defect level
Include (or not) test automation
Define testing responsibilities
Following the plan helps:
Prevent delays in the application roll-out
Increase user adoption
QA Team Integration
QA team must be involved in the projectfrom the beginning
Avoid delays, refactoring and rework
Enables more frequent product releases
Responsibilities include:
Designing test cases as the stories are implemented
Testing stories and features as they are delivered
The purpose is:
Ensuring quality early and continuously in the development process
Avoiding a large backlog of defects at the end of the project
The Outsystems Method [14 - 46,7%]
Project Delivery Methodology
OutSystems Uses an Agile Methodology
Timebox Principle
Iterative Development
Transparent Project Management
Collaborative Approach
Full Visibility on Execution Progress
Room for Feedback and Changes
Flexibility
Sharing the Methodology
Share the methodology with the customer
Process of coaching
Accommodate any necessary learning curve
Objective: Keep high speed and deliver maximum value with quality
Mitigate risks
Delivery Methodology Focus
Feature Negotiation
Value Driven Deliveries
Fast Reaction to Changes
Fixed Time and Resources
Project Delivery Methodology Phases
Setup
1 Week
Project Preparation
Initiation
1-2 Week
High Level Iteration settlement
Iteration 1 - User Stories definition
Delivery Practice Alignment
DoR and DOD
App Skeleton
Iteration Developement
2-3 Week Iterations
Shape
Shape next iteration
New Backlog
Prioritize backlog
Analyze and define User Stories
Build
Deliver current iteration
User Story delivery
Accept
Acceptance of previous iteration
Validate and accept delivered User Stories
Solution Release
1-4 Week
Testing & Customer Acceptance
Close rollout preparation
Stabilization
Release Planning
Go live at phase end
Post Production
1 Week
Monitoring
Tuning
Feedback
Minor CR´s
Closure
1 Week
Wrap-up
Share
Improve
Roles & Responsabilities
A Community of Professionals
OutSystems projects are heavily people-centric and collaborative!
Management Team
Composed by customer and delivery team members
Provides direction
Removes obstacles
Makes sure the objectives are accomplished
Business Sponsor
Provides business direction and guidance
Decision-making authority
Involved in feature negotiation
Available on demos and steering meetings
Project Manager
Manages PMO process
Manages & mitigates risks / issues
Manages 3rd Party interactions
Manages timeline
Product Owner
Expresses Product Backlog items
Establishes priorities in the Backlog
Ensures Backlog visibility and transparency
Ensures all Backlog User Stories are understood
Accepts or delegates acceptance of User Stories
Delivery Specialist
Represent the business to the Delivery Team
Manage Backlog with Product Owner
Negotiate Iteration features
Conduct feature delivery demos
Co-manage & mitigates risks/ issues
Manage project delivery Timeline
IT Manager
Manages infrastructure availability
Manages integrations / data migration
Manages 3rd party interactions
IT Architect
Provides roadmaps defining guidelines
Sets best practices
Ensures IT vs. Business strategy alignment
Business Analysis Team
Part of the Customer Team
Ensure User Stories accuracy, quality, quantity and prioritization
Ensure Product quality
Business Analyst
Delegated decision-making authority
Delegated feature negotiation and feature delivery acceptance
Performs Business Analysis
Writes User Stories and Acceptance Criteria
Coordinates user acceptance testing *
Delivery Team
Deliver quality products as specified by the Business Analysis Team
Technical Lead
Manages delivery team
Size, assigns and commits to features
Architects the solution
Supports feature delivery demos
Developers
Develops technical solution
Tests technical solution
Follows engineering best practices
Quality Assurance Team
Part of the Customer team
Testing approach
Estimation
Execution
Product Quality
QA Team
Defines test plan, cases, scripts
Provides continuous feedback on delivered stories
Delegated User Story acceptance
Coordinates user acceptance testing
DevSecOps Experts
Application and infrastructure security and support.
DevSecOps Expert Team
Ensures rapid and frequent development cycles
Defines and sets up the automated processes and the needed infrastructure
Integrates security measures with minimal disruption to operations
UX/UI Experts
Usability and innovative look and feel of the product.
UX/UI Expert Team
Collaborates on Vision and Personas
Defines and monitors UX Metrics
Conducts user interviews
Creates low and high resolution mockups
Conducts usability testing
Ensures product meets usability and accessibility standards
Summary
Different teams will work together to deliver a great solution using OutSystems!
Initiation
Iteration Development
Iteration Development Overview
Typical iteration lasts 2 to 3 weeks
Incremental and iterative processes to implement the solution
Activities run in 3 concurrent tracks
Shape
Prepare for the next iteration
Write and prioritize the backlog
Analyze and refine candidate user stories during Backlog Refinement session(s) toward Definition of Ready
Settle “ready” stories for the next iteration in the Iteration Planning meeting
Important
Goal: Ensure the next iteration has User Stories fully known and detailed
Mitigate the risk of impacts in User Stories during Refinement such as:
Important questions left undiscovered or unanswered
Discovering the need to add or change something
An iteration is an agreement:
Development team delivers what was planned
Customer commits to not change requirements during delivery
Activities
Write Backlog: Business Analyst to produce a first (complete) version of the highest priority User Story
Epics
Features
User Stories
Backlog Refinement: The development team participates in tuning, validating and estimating User Stories (Definition of Ready)
Refinement: tuning + validation + estimation of User Stories
User Stories are shared before each refinement session
The entire development team should participate
Verify INVEST principles
Confirm with key-users when necessary
No core questions left behind!
Only then estimate!
Estimates get more accurate
Iteration Planning: Check the list of User Stories that meet the DoR checklist and agree on the set of User Stories that will be part of the next iteration
Agree which User Stories will be part of the iteration
Evaluate “ready” backlog items based on priority
Estimate the team capacity for the iteration based on number of developers, holidays, scheduled time off (55% development, 15% testing, 30% stabilization)
Negotiate the final stories to include in the iteration
The Iteration Planning should result in a commitmentfrom the whole Development Team
Team has the final decision on what they are willing to commit to for an iteration
Build
Deliver scope for current iteration
Daily Scrum
Demo to business users
Retrospective to assess iteration and improve team performance
Important
Goal: Deliver a high quality product per the iteration commitment
Develop using best practices for coding and testing
Use daily scrums to track progress and detect issues
Use early feedback to increase quality and value
Impress the customer with an impactful demo of the iteration product
Retrospect for continuous improvement
Activities
During this track, the Development team will be focused on:
Developing the User Stories based on Acceptance Criteria and considering the defined test cases
Apply the “be the user” mindset to ensure the right perspective during implementation and testing
Delivering with best practices, quality, on time and compliant to the designed solution architecture
Ensuring usability, a great User Interface, scalability and performance
Comprehensively testing (mostly unit, integration and usability testing)
Preparing the intermediate demo to a small audience to identify bugs, deployment, configuration and data issues.
Additionally, the entire team also participates in:
A Daily Scrum to discuss progress, plans, and take action on potential blockers
An intermediate demo and stabilization to detect and solve bugs and usability issues before delivery
A demo or iteration review with product owner and stakeholders
Show customer what was accomplished during iteration
Compare to commitment at beginning of iteration
An Iteration Retrospective to
acknowledge achievements,
assess iteration success and
decide on improvement actions for team performance
Accept
Close out the previous iteration *
Support the customer during validation
Accept User Stories on UAT testing achieving Definition of Done
Log feedback and resolve small bugs and minor changes with capacity reserve
* Alternatively, perform at end of current iteration for its stories
Important
Goal: Customer formally accepts that what was delivered meets the acceptance criteria of the user story
Testing of acceptance criteria in user stories
Logging of feedback
Classification and Triaging of feedback
Resolution of bugs to stabilize and implementation of quick wins to ensure adoption
Activities
During this track, the team is focused on:
Supporting the customer during acceptance testing
Analyzing and triaging logged feedback
Defects
Ambiguous acceptance criteria
Improvements or new features
Prioritizing feedback for immediate resolution
Ensuring acceptance of the delivered user stories
Results in a better quality of delivery and assurance of alignment.
User Story Lifecycle
Write Backlog
Refine Backlog
Iteration Planning
Development & Test
Read to feedback
First round of feedback (usually by BA and Testers)
Demo
Demo and get business feedback US validation
Discover new US after testing sessions (KU)
Solution Release
Solution Release in a Nutshell
Stakeholders and users test the entire application end-to-end thoroughly
Delivery team make the final improvements before the new solution goes live
At the end of this stage, the new solution is live, and the business starts benefiting from it!
Major Activities
End-to-End User Acceptance testing
Rollout plan and handover documentation
Go/No Go definition
Training
Rollout Plan
Step by step technical deployment script for a seamless installation of the solution and the rollback scenario
Validate readiness of infrastructure and third party integrations
Consider the rollback plan
Complete path to switch from the former application to the new one
Understand the business impact of the solution
Ensure preparation of individuals, teams and organization
Ensure value will be delivered to business!
Training
Work towards an intuitive solution!
The Business Analyst or a key-user champion are usually responsible for the Training
It can consist on:
Train the Trainer classroom approach
Recorded video session that is shared with the end-users
Documentation
Produce the last version of technical documentation for the solution
OutSystems provides an automated way to generate this - OutDoc
Ensure proper project handover to IT and business from the customer
All relevant technical and functional aspects of the application that might not have been yet discussed or passed on a digital format
Documents and user guides
Project Control
Finalize any last work items that may remain!
Address the existing list of pending feedback produced during
Iteration validation
Final UAT tests taking place during this period
No new developments or any other major tasks should take place in this period
Involve the right stakeholders if necessary!
Go/No-Go Decision!
Testing
Perform end-to-end testing to confirm the fulfillment of user needs and business goals
Scheduled sessions with selected team members
Load / Stress tests
Building test scripts
Executing multiple scenarios
Data analysis
Report creation
Stabilization and UAT
Final acceptance for the delivered functionality that hasn’t been accepted yet
Regular release cycle to deploy hotfixes
Should include all details and expected behaviors
Should be applied in all environments
Key to success
Go/No-Go criteria agreement beforehand
Establish communication plans and decision factors
Go/No-Go meetings with decision making stakeholders
Risk Management [2 - 6,7%]
Definitions
Risk: potential of gaining or losing something of value
Risk Analysis: helps a team understand uncertainties that can affect the project outcome
Risk Management: process of identifying, analyzing and responding to risk factors
Worst Project Outcomes
Deliver the wrong thing
Deliver the right thing, but too late
Deliver something that doesn’t work
Impacts
Customer not satisfied
Low adoption
Loss of trust
Project failure
Risk Management in Agile projects
Agile projects already include‘implicit’ risk management!
Iterative nature of projects
Small, co-located teams
Constant alignment
Improvement methods
Spikes
Relying only on implicit nature of risk management makes it difficult to:
Identify all risks
Measure the risk impact
Find the right timing to address a risky situation
Tendency to overlook things outside of the immediate line of sight!
Structured Method for Risk Management
Incorporate into iterative and continuous work the team is already doing
Continuous 5 step process
Identify
Assess
Plan
Act
Track
Ties into the Delivery Method
Initiation
Status Reporting
Decision for Explicit Risk Management
Complex projects, complex business rules and business process changes
Distributed team members and stakeholders
Mission critical applications or multiple concurrent projects
Team new to Agile practices or adopting a non-variant
How Much Structure?
It depends on:
Reporting / risk analytics requirements
Impact of success / failure of project
Continuous 5 step process
Identify
What
When
Method 1: SWOT Analysis
Helpful/Harmful - Internal/External
Useful to uncover strengths and opportunities to explore
Ask questions for each quadrant○ Strengths, Opportunities○ Weaknesses, Threats
Method 2: Risk Drivers
Areas with potential risk exposure to analyze
Defined with stakeholders and project team at start of project
Can vary based on the project and customer
Assess
Classify
Based on SWOT Analysis
Risk Management is primarily interested in the Harmful column
Align to the risk drivers
Highlight the biggest areas of weakness of the project or company
Usually known when risk is identified
Quantify
SME determines probability and impact
Including Days of Loss
Risk Score - determined via Risk Matrix
Impact
Probability
Risk Score
Plan
Agree on Risk Responses with stakeholders and project team
Avoid - take a different project path to avoid the risk condition
Transfer - the risk is being shifted to someone outside of the project
Accept - a contingency plan is in place should the risk occur or has low impact or likelihood
Mitigate - take action to make the risk less probable and of lower impact
Review/define the mitigation steps for each “Mitigate” risk
Prioritize risks based on Threat/Weakness and Risk Score
Colors correspond to the Risk Score squares in the Risk Matrix
○ Address highest risk as early as possible in the project
Act
The detailed mitigation plan defines the details of the action
Risk Score and Priority define the action’s urgency and communication path
Make sure each action has an owner for both execution and communication
Track
Risk Log - review, monitor, reassess risks
Iteration planning
Status update meetings
Per frequency of prescribed Risk Action
Risk Burndown Chart - tracking tool
Risk Exposure = Probability * Days of Loss
Risk should burn down to green closer to the completion of the project
Risks not reduced to minimal by the end of the project indicate ineffective risk management
Only track the most important risks!
Key Points
Make risks visible
Choose the right level of structure
Identify and assess risks with the right people
Continuously monitor and act on the most important risks
Use a risk burndown chart
Include risk management in activities already performed
● Don’t merely rely on mechanics - Keep eyes and ears open!
Project Management Metrics [4 - 13.3%]
Metrics as a Game Changer
Possible Scenarios
Quality issues, scope problems and budget issues appear
Technically doing everything right, but can’t get the customer over the finish line
Everything was going well for the first two Iterations, but now you cannot close all stories
How Can We Help?
Which metrics can bring the most value in to detect problems early and adapt our ways of working?
How to make good use of specific project management metrics to avoid risks, project delays and budget problems?
Why Do We Use Metrics?
Metrics help Delivery Specialists proactively stay on top of common problem areas and take appropriate actions with more confidence!
Status and health of your project
Communicate project status in a clear and objective way
Project Risks and their severity
Foresee, track and mitigate problem areas before they go “critical”
Team productivity
Adjust workflow, tasks, or team
Quality of work
Adapt practices or address/defend unjustified “bad quality” statements
Project progress on feature delivery
Meet, set, reset customer expectations
Metrics by Category
Scope
Estimation
Productivity
Quality
Lead Time
Where Do We Benefit From Metrics?
Initiation
Iteration Development
Solution Release
Post Production
Closure
Create Meaningful Data
Most metrics are calculated using one (or more) of these
Story Points Estimate
Hour Estimates
Issue Count
Status Transitions
Hour Logs
Specific data fields
Key Practices and Processes
DoR/DoD - Lifecycles
Project Setup
Scope Alignment Checkpoint
Story Refinement Process
Feedback Triage Process
Estimation of Epics
Developers Task Time Logging
Status Updates
Risk/Issue Management
Retrospectives
Layers of Key Practices & Processes
Workflows & Processes
Functional User Stories
Customer Feedback
Internal Feedback
Estimates and Time Logging
Epic Estimation
US Estimation
Log Time
Feedback classification
Defect Impact
Defect Root Cause
Linked Issue
Key Metrics
Metrics by Category
Scope
Scope Management
Remaining effort vs Capacity
Early awareness of the risk of not being able to deliver the expected remaining scope within the project budget.
Cerimony
Planning
Status Meeting
Phase
Initiation
Iteration Development
Backlog Definition Quality
Changes after US development
Alerts to potential deviation from project vision when number of improvements, and time spent on them, is out of sync with the time spent on original US.
Phase
Iteration Development
Cerimony
Planning
Status Meeting
Retrospecive
Scope Acceptance
User Story acceptance ratio
Evaluate overall delivery progress and its alignment with the customer’s expectation.
Cerimony
Planning
Status Meeting
Phase
Iteration Development
Provide early warning signals for
Meeting the customer’s original expectations
Deviating from the Project Vision and Goals
Estimation
Estimate Size
Average User Story size
Monitor User Story size as a measure of adherence to best practices and predictability of results.
Phase
Iteration Development
Cerimony
Planning
Estimation Accuracy
User Story estimate vs actual
Track accuracy of estimates and calibrate over time to improve predictability for Iteration planning throughout the project.
Phase
Iteration Development
Cerimony
Scrum
Retrospective
Measuring how well we are mitigating project risk by
Keeping user story complexity low
Keeping quality of story details high
Improving predictability of Iteration planning
Productivity
Velocity
Planning predictability
Predictability for Iteration planning based on how many story points the team is able to deliver.
Phase
Iteration Development
Cerimony
Planning
Status Meeting
Scrum
Retrospective
Iteration planning Quality
Committed vs Delivered
Team effectiveness in delivering Iteration goals by analysing gap between team’s commitment and what was actually delivered.
Phase
Iteration Development
Cerimony
Planning
Scrum
Retrospective
Iteration Burndown
Iteration progress
Shows the completed work per day against the projected rate of completion. Indicates if the team is on track to deliver the expected goal within the Iteration.
Phase
Iteration Development
Cerimony
Scrum
Retrospective
Provide insight into
How to deliver new features faster
How to better meet your iteration commitments
Whether you are going to meet your Iteration commitments
Quality
Delivery Quality
Defects per Iteration
Measure of development quality, team proficiency, User Story quality, with the intent to identify most challenging Iterations.
Phase
Iteration Development
Solution Release
Cerimony
Planning
Status Meeting
Scrum
Retrospective
Defect Impact
Defect impact score per Iteration
Distribution of defects by level of impact. Allows the evaluation of delivery quality and severity of the defects being opened
Phase
Iteration Development
Solution Release
Cerimony
Status Meeting
Scrum
Retrospective
Defect Reopen Rate
Reopened defects (%)
Evaluate quality of defect resolution and management process - analysis, development, testing, deployment and acceptance.
Phase
Iteration Development
Solution Release
Cerimony
Retrospective
Post Acceptance defects
Defects opened after User Story is done
Insight concerning quality of acceptance criteria or tests performed as part of acceptance, by displaying number of defects opened for US after acceptance
Phase
Iteration Development
Solution Release
Cerimony
Planning
Status Meeting
Scrum
Retrospective
Defect Root Causes
Defects per root cause
Track the root causes of defects to identify systemic problem areas and help identify and take targeted measures for resolution
Phase
Iteration Development
Solution Release
Cerimony
Status Meeting
Retrospective
Work together to help us define actions based on measures of:
Quality of User Stories and acceptance criteria
Clarity of logged defects and feedback provided
Distribution of defect root causes
Impact of defects
Distribution of defects across iterations and features
Lead Time
Defect Aging
Defect resolution timeline
Analyse defect aging to understand if the team is able to cope with defects rate/complexity and whether adjustments are required
Phase
Iteration Development
Solution Release
Cerimony
Retrospective
Speed of Acceptance
Average time from Delivered to Done
Evaluate the average time it takes to accept User Stories; to gauge the customer’s commitment to the project delivery and identify the potential risk to the plan
Phase
Iteration Development
Solution Release
Ceremony
Status Meeting
Defect Resolution Effort Distribution
Defect resolution effort by root cause
Track the effort to resolve defects by their root cause, to target actions against those with the highest resolution effort first
Phase
Iteration Development
Solution Release
Ceremony
Retrospective
Great predictors of whether value and quality will be delivered on time
Are we closing defects faster than we are logging them?
● What is the risk from not accepting stories at the right pace?
● Are we focusing improvement efforts on where we spend the most time on resolutions?
Ceremonies
Planning
Status Meeting
Scrum
Restrospective
Metrics in Action
New Workflows & Processes
Specific workflows have been defined for
Stories
Feedback
Internal Feedback
Helps the process and ensures alignment for consistency purposes
DoR and DoD must be aligned with these workflows to support the metrics.
Why?
Give visibility to the way work is managed
Better alignment across the team and stakeholders
How?
Stories follow workflows ensuring needed stages are met
Internal feedback should be added as a correction task
Feedback received after “Ready for Acceptance” should go through the feedback workflow
Estimates
Metrics need estimates in:
Hours
Story Points
The only way to use all the metrics is to use both estimates!
Planning the Iteration and estimating Epics and User Stories is a team activity!
Be mindful of estimates.
Why?
Predictability, accountability, continuous improvement
To use all of the Metrics to supplement all customer interactions, with facts and data
How?
Epics - using Hours during Initiation
User Stories - using Story Points during Refinement
Tasks - using Hours during Iteration Planning and summarized into the User Story original estimate, at the end of the Iteration Planning
Time Logging
Why?
Ensure the Team’s predictability, accountability
Ensure meaningful data is provided to help interpret metrics
How?
Log all hours spent daily in Stories and Defects during all stages of development
Iteration Development
Solution Release
Metrics by Used Measure
Hours Estimate
Scope
Scope Management
Productivity
Iteration Burndown*
Iteration Planning Quality*
Estimation
Estimation Accuracy
Estimate Size*
Story Points Estimate
Productivity
Velocity
Iteration Burndown*
Iteration Planning Quality*
Estimation
Estimate Size*
Issue Count
Quality
Delivery Quality
Defect Impact
Post Acceptance Defects
Defect Reopen Rate
Defect Root Causes
Scope
Backlog Definition Quality
Status Transition
Lead Time
Defect Aging
Speed of Acceptance
Scope
Scope Acceptance
Time Logging
Lead Time
Defect Resolution Effort Distribution
Estimation
Estimation Accuracy
Productivity
Velocity
Feedback Classification
Why?
Ensure a quick and assertive way of identifying and solving the “small crisis”
Understand patterns and take corrective actions
How?
Feedback should follow the new lifecycles and the new DoR and DoD
Identify the Root Cause of each defect
Classify each defect according to its Impact on the project
Small Adjustments, New Possibilities
Project Delivery Methodology already does most of what is needed to implement metrics
Small adjustments are necessary in existing ceremonies and processes