This document provides an overview of agile estimation techniques for fixed price projects. It discusses challenges with upfront estimation for fixed price contracts and recommends estimating projects using fixed costs rather than fixed scope. The document outlines a 14-step framework for agile story point estimation, planning and scheduling that includes defining requirements, user stories, estimating story points using matrices, computing initial velocity, and determining schedules and additional efforts. It also discusses change management processes and factors that can impact velocity like team expertise and requirement clarity.
Estimating with MAGIC Approach – Measure, Analyze, Improve and Control without ‘Guess’ work
#) Measure & Analyze using ‘Story Point Matrix’ based on Functional & Technical Analysis
#)Improve & Control using Statistical Data Modeling based on Empirical Data extracted from agile project management tool
Agile Patterns: Agile Estimation
We’re agile, so we don’t have to estimate and have no deadlines, right? Wrong! This session will consist of review of the problem with estimation in projects today and then an overview of the concept of agile estimation and the notion of re-estimation. We’ll learn about user stories, story points, team velocity, how to apply them all to estimation and iterative re-estimation. We will take a look at the cone of uncertainty and how to use it to your advantage. We’ll then take a look at the tools we will use for Agile Estimation, including planning poker, Visual Studio Team System, and much more. This is a very interactive session, so bring a lot of questions!
Introduction to Agile Estimation & PlanningAmaad Qureshi
Presented by Natasha Hill & Amaad Qureshi
In this session, we will be covering the techniques of estimating Epics, Features and User Stories on an Agile project and then of creating iteration and release plans from these artefacts.
Agenda
1. Why traditional estimation approaches fail
2. What makes a good Agile Estimating and Planning approach.
3. Story points vs. Ideal Days
4. Estimating product backlog items with Planning Poker
5. Iteration planning - looking ahead and estimating no more than a few week ahead.
6. Release planning - creating a longer term plan, typically looking ahead, 3-6 months
7. Q&A
A. Kamran's DoD and DoR: Definition of Done and Definition of Ready in ScrumArman Kamran
Definition of what constitutes as a "Ready" PBI (Product Backlog Item) for the Development team to pull into a Sprint, and what makes that PBI considered as "Done" for the Product Owner to review and accept or reject, is a vital factor in building and maintaining a functional and ever improving relationship between PO and the Dev Team.
Here he look at best practices in doing so!
Estimating with MAGIC Approach – Measure, Analyze, Improve and Control without ‘Guess’ work
#) Measure & Analyze using ‘Story Point Matrix’ based on Functional & Technical Analysis
#)Improve & Control using Statistical Data Modeling based on Empirical Data extracted from agile project management tool
Agile Patterns: Agile Estimation
We’re agile, so we don’t have to estimate and have no deadlines, right? Wrong! This session will consist of review of the problem with estimation in projects today and then an overview of the concept of agile estimation and the notion of re-estimation. We’ll learn about user stories, story points, team velocity, how to apply them all to estimation and iterative re-estimation. We will take a look at the cone of uncertainty and how to use it to your advantage. We’ll then take a look at the tools we will use for Agile Estimation, including planning poker, Visual Studio Team System, and much more. This is a very interactive session, so bring a lot of questions!
Introduction to Agile Estimation & PlanningAmaad Qureshi
Presented by Natasha Hill & Amaad Qureshi
In this session, we will be covering the techniques of estimating Epics, Features and User Stories on an Agile project and then of creating iteration and release plans from these artefacts.
Agenda
1. Why traditional estimation approaches fail
2. What makes a good Agile Estimating and Planning approach.
3. Story points vs. Ideal Days
4. Estimating product backlog items with Planning Poker
5. Iteration planning - looking ahead and estimating no more than a few week ahead.
6. Release planning - creating a longer term plan, typically looking ahead, 3-6 months
7. Q&A
A. Kamran's DoD and DoR: Definition of Done and Definition of Ready in ScrumArman Kamran
Definition of what constitutes as a "Ready" PBI (Product Backlog Item) for the Development team to pull into a Sprint, and what makes that PBI considered as "Done" for the Product Owner to review and accept or reject, is a vital factor in building and maintaining a functional and ever improving relationship between PO and the Dev Team.
Here he look at best practices in doing so!
Presenter:
Dr. Gail Ferreira, Agile Practice Leader, MATRIX Resources, San Francisco Center of Excellence
Rapid scale directly impacts all levels of decision-making, planning, execution, culture, and communications for executives in hypergrowth companies. In this session, we will discuss how to organize, support, and tailor agile practices for teams and sub-teams in companies with a rapid growth cycle. We will share contemporary case studies of hypergrowth companies who have delivered agile at scale.
Topics will include:
• Basic agile and lean methods
• Scrum of Scrums
• SAFe
• Disciplined Agile Delivery (DAD)
• Agility at Scale (Ambler/Lines)
• Spotify model (Tribes, Squads, Chapters & Guilds, DSDM).
This presentation includes an overview of the various estimation techniques used in Agile projects. I've also put in a slide for explaining the importance of business value for Agile requirements. A simple mechanism on capacity planning before weaving it all together to come up with a reasonably foolproof plan.
Product Backlog - Refinement and Prioritization TechniquesVikash Karuna
This presentation describes the important techniques used in Product Backlog refinement and prioritization in Agile development. The various techniques described here are very useful for product managers, product owners, scrum masters, and agile teams.
This slide gives an excellent overview of Agile Planning and Estimation.
Will be really helpful, if presented to a Scrum/Agile Team to understand activities related to Release Planning, Sprint Planning and Estimation
My main goal is to share and make you experiment some of the techniques that I use when transforming teams into high-perfoming agile teams, by providing you with four (4) different ways to estimate projects in Agile.
Contains a quick review of the Scrum process, talks about the dangers of trying to map PMBOK to Scrum, and then tries to talk about the concepts behind managing an Agile project using Scrum.
When I needed to do presentations of Scrum to executives and students, I started to look for existing ones. Most presentations I found were very good for detailed presentations or training. But what I was looking for was a presentation I could give in less than 15 minutes (or more if I wanted). Most of them also contained out dated content. For example, the latest changes in the Scrum framework were not present and what has been removed was still there.
UPDATE VERSION : https://www.slideshare.net/pmengal/scrum-in-ten-slides-v20-2018
Ever wonder why Agile teams swear by relative estimation? My teams improved sprint planning efforts by a factor or 3, once we started using relative estimation.
Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world!
“It's better to be roughly right, than precisely wrong!”
~ John Maynard Keyenes
The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck!
PROBLEMS WITH TIME-BASED ESTIMATES
-Teams spend too much time trying to get it right
-Lack of confidence/experience can lead to people being either optimistic or pessimistic
-Timeline you are estimating may be too far in the future
-Due to long timeline, there are too many risks, unknowns, changes or dependencies!
WHY USE RELATIVE ESTIMATION?
-Allows a quick comparison of stories in the backlog
-Allows you to select a predictable volume of work to do in a sprint
-Uses a simple arbitrary scale
-Allows PO to make trade-offs and take on the most valuable stories next
ESTIMATION TIPS
-Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile.
-The team estimates the story, not management nor the customer.
-Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues.
-Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes.
-Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready.
-Only pull into your sprint, stories that are refined and estimated.
-Break down stories that are large, into smaller slivers of value to optimize your flow.
-Don’t sweat it if you get it wrong, teams often do early on but improve over time.
Estimating is hard to get right;
Why is estimating hard to get right?;
Why do we need to estimate;
Agile estimating and planning;
Determine the teams velocity;
Identify features and stories;
Define stories or features;
Planning Poker;
Agile Release Plan;
What if you don’t know the teams velocity?;
Estimating from ideal team structure;
The effect of rework;
Proposals and SOW’s;
Presenter:
Dr. Gail Ferreira, Agile Practice Leader, MATRIX Resources, San Francisco Center of Excellence
Rapid scale directly impacts all levels of decision-making, planning, execution, culture, and communications for executives in hypergrowth companies. In this session, we will discuss how to organize, support, and tailor agile practices for teams and sub-teams in companies with a rapid growth cycle. We will share contemporary case studies of hypergrowth companies who have delivered agile at scale.
Topics will include:
• Basic agile and lean methods
• Scrum of Scrums
• SAFe
• Disciplined Agile Delivery (DAD)
• Agility at Scale (Ambler/Lines)
• Spotify model (Tribes, Squads, Chapters & Guilds, DSDM).
This presentation includes an overview of the various estimation techniques used in Agile projects. I've also put in a slide for explaining the importance of business value for Agile requirements. A simple mechanism on capacity planning before weaving it all together to come up with a reasonably foolproof plan.
Product Backlog - Refinement and Prioritization TechniquesVikash Karuna
This presentation describes the important techniques used in Product Backlog refinement and prioritization in Agile development. The various techniques described here are very useful for product managers, product owners, scrum masters, and agile teams.
This slide gives an excellent overview of Agile Planning and Estimation.
Will be really helpful, if presented to a Scrum/Agile Team to understand activities related to Release Planning, Sprint Planning and Estimation
My main goal is to share and make you experiment some of the techniques that I use when transforming teams into high-perfoming agile teams, by providing you with four (4) different ways to estimate projects in Agile.
Contains a quick review of the Scrum process, talks about the dangers of trying to map PMBOK to Scrum, and then tries to talk about the concepts behind managing an Agile project using Scrum.
When I needed to do presentations of Scrum to executives and students, I started to look for existing ones. Most presentations I found were very good for detailed presentations or training. But what I was looking for was a presentation I could give in less than 15 minutes (or more if I wanted). Most of them also contained out dated content. For example, the latest changes in the Scrum framework were not present and what has been removed was still there.
UPDATE VERSION : https://www.slideshare.net/pmengal/scrum-in-ten-slides-v20-2018
Ever wonder why Agile teams swear by relative estimation? My teams improved sprint planning efforts by a factor or 3, once we started using relative estimation.
Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world!
“It's better to be roughly right, than precisely wrong!”
~ John Maynard Keyenes
The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck!
PROBLEMS WITH TIME-BASED ESTIMATES
-Teams spend too much time trying to get it right
-Lack of confidence/experience can lead to people being either optimistic or pessimistic
-Timeline you are estimating may be too far in the future
-Due to long timeline, there are too many risks, unknowns, changes or dependencies!
WHY USE RELATIVE ESTIMATION?
-Allows a quick comparison of stories in the backlog
-Allows you to select a predictable volume of work to do in a sprint
-Uses a simple arbitrary scale
-Allows PO to make trade-offs and take on the most valuable stories next
ESTIMATION TIPS
-Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile.
-The team estimates the story, not management nor the customer.
-Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues.
-Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes.
-Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready.
-Only pull into your sprint, stories that are refined and estimated.
-Break down stories that are large, into smaller slivers of value to optimize your flow.
-Don’t sweat it if you get it wrong, teams often do early on but improve over time.
Estimating is hard to get right;
Why is estimating hard to get right?;
Why do we need to estimate;
Agile estimating and planning;
Determine the teams velocity;
Identify features and stories;
Define stories or features;
Planning Poker;
Agile Release Plan;
What if you don’t know the teams velocity?;
Estimating from ideal team structure;
The effect of rework;
Proposals and SOW’s;
In many organizations, bottom up estimation of software development projects is still the way to go. Management feels that top-down (parametric) estimation models require too much effort and cost. In this presentation, a random selection of 10 bids are analyzed and the bottom-up estimates and top-down estimates are compared with regard to accuracy and effort spend.
AEM Maxed = Agile + Automation.
Time Warner Cable and iCiDIGITAL reveal how a stellar agile development team delivers an award-winning website using Adobe Experience Manager. Highlights include team interactions, scaling the team, collaborative moments, testing automation, and continuous integration. Also, they will share previews of a few open source attractions that will accelerate your Adobe Experience Manager delivery.
Case Study: Time Warner Cable's Formula for Maximizing Adobe Experience Manager Mark Kelley
Time Warner Cable and iCiDIGITAL reveal how a stellar agile development team delivers an award-winning website using Adobe Experience Manager. Highlights include team interactions, scaling the team, collaborative moments, testing automation, and continuous integration. Also, they share previews of a few open source attractions that will accelerate your Adobe Experience Manager delivery.
Software_effort_estimation for Software engineering.pdfsnehan789
calculating software effort estimation for subjects like software engineering and software project management all according to your college preference on the subject
Accelerate Enterprise Software Engineering with PlatformlessWSO2
Key takeaways:
Challenges of building platforms and the benefits of platformless.
Key principles of platformless, including API-first, cloud-native middleware, platform engineering, and developer experience.
How Choreo enables the platformless experience.
How key concepts like application architecture, domain-driven design, zero trust, and cell-based architecture are inherently a part of Choreo.
Demo of an end-to-end app built and deployed on Choreo.
Innovating Inference - Remote Triggering of Large Language Models on HPC Clus...Globus
Large Language Models (LLMs) are currently the center of attention in the tech world, particularly for their potential to advance research. In this presentation, we'll explore a straightforward and effective method for quickly initiating inference runs on supercomputers using the vLLM tool with Globus Compute, specifically on the Polaris system at ALCF. We'll begin by briefly discussing the popularity and applications of LLMs in various fields. Following this, we will introduce the vLLM tool, and explain how it integrates with Globus Compute to efficiently manage LLM operations on Polaris. Attendees will learn the practical aspects of setting up and remotely triggering LLMs from local machines, focusing on ease of use and efficiency. This talk is ideal for researchers and practitioners looking to leverage the power of LLMs in their work, offering a clear guide to harnessing supercomputing resources for quick and effective LLM inference.
Developing Distributed High-performance Computing Capabilities of an Open Sci...Globus
COVID-19 had an unprecedented impact on scientific collaboration. The pandemic and its broad response from the scientific community has forged new relationships among public health practitioners, mathematical modelers, and scientific computing specialists, while revealing critical gaps in exploiting advanced computing systems to support urgent decision making. Informed by our team’s work in applying high-performance computing in support of public health decision makers during the COVID-19 pandemic, we present how Globus technologies are enabling the development of an open science platform for robust epidemic analysis, with the goal of collaborative, secure, distributed, on-demand, and fast time-to-solution analyses to support public health.
Globus Compute wth IRI Workflows - GlobusWorld 2024Globus
As part of the DOE Integrated Research Infrastructure (IRI) program, NERSC at Lawrence Berkeley National Lab and ALCF at Argonne National Lab are working closely with General Atomics on accelerating the computing requirements of the DIII-D experiment. As part of the work the team is investigating ways to speedup the time to solution for many different parts of the DIII-D workflow including how they run jobs on HPC systems. One of these routes is looking at Globus Compute as a way to replace the current method for managing tasks and we describe a brief proof of concept showing how Globus Compute could help to schedule jobs and be a tool to connect compute at different facilities.
Quarkus Hidden and Forbidden ExtensionsMax Andersen
Quarkus has a vast extension ecosystem and is known for its subsonic and subatomic feature set. Some of these features are not as well known, and some extensions are less talked about, but that does not make them less interesting - quite the opposite.
Come join this talk to see some tips and tricks for using Quarkus and some of the lesser known features, extensions and development techniques.
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...Juraj Vysvader
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I didn't get rich from it but it did have 63K downloads (powered possible tens of thousands of websites).
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteGoogle
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
👉👉 Click Here To Get More Info 👇👇
https://sumonreview.com/ai-pilot-review/
AI Pilot Review: Key Features
✅Deploy AI expert bots in Any Niche With Just A Click
✅With one keyword, generate complete funnels, websites, landing pages, and more.
✅More than 85 AI features are included in the AI pilot.
✅No setup or configuration; use your voice (like Siri) to do whatever you want.
✅You Can Use AI Pilot To Create your version of AI Pilot And Charge People For It…
✅ZERO Manual Work With AI Pilot. Never write, Design, Or Code Again.
✅ZERO Limits On Features Or Usages
✅Use Our AI-powered Traffic To Get Hundreds Of Customers
✅No Complicated Setup: Get Up And Running In 2 Minutes
✅99.99% Up-Time Guaranteed
✅30 Days Money-Back Guarantee
✅ZERO Upfront Cost
See My Other Reviews Article:
(1) TubeTrivia AI Review: https://sumonreview.com/tubetrivia-ai-review
(2) SocioWave Review: https://sumonreview.com/sociowave-review
(3) AI Partner & Profit Review: https://sumonreview.com/ai-partner-profit-review
(4) AI Ebook Suite Review: https://sumonreview.com/ai-ebook-suite-review
Understanding Globus Data Transfers with NetSageGlobus
NetSage is an open privacy-aware network measurement, analysis, and visualization service designed to help end-users visualize and reason about large data transfers. NetSage traditionally has used a combination of passive measurements, including SNMP and flow data, as well as active measurements, mainly perfSONAR, to provide longitudinal network performance data visualization. It has been deployed by dozens of networks world wide, and is supported domestically by the Engagement and Performance Operations Center (EPOC), NSF #2328479. We have recently expanded the NetSage data sources to include logs for Globus data transfers, following the same privacy-preserving approach as for Flow data. Using the logs for the Texas Advanced Computing Center (TACC) as an example, this talk will walk through several different example use cases that NetSage can answer, including: Who is using Globus to share data with my institution, and what kind of performance are they able to achieve? How many transfers has Globus supported for us? Which sites are we sharing the most data with, and how is that changing over time? How is my site using Globus to move data internally, and what kind of performance do we see for those transfers? What percentage of data transfers at my institution used Globus, and how did the overall data transfer performance compare to the Globus users?
Experience our free, in-depth three-part Tendenci Platform Corporate Membership Management workshop series! In Session 1 on May 14th, 2024, we began with an Introduction and Setup, mastering the configuration of your Corporate Membership Module settings to establish membership types, applications, and more. Then, on May 16th, 2024, in Session 2, we focused on binding individual members to a Corporate Membership and Corporate Reps, teaching you how to add individual members and assign Corporate Representatives to manage dues, renewals, and associated members. Finally, on May 28th, 2024, in Session 3, we covered questions and concerns, addressing any queries or issues you may have.
For more Tendenci AMS events, check out www.tendenci.com/events
Cyaniclab : Software Development Agency Portfolio.pdfCyanic lab
CyanicLab, an offshore custom software development company based in Sweden,India, Finland, is your go-to partner for startup development and innovative web design solutions. Our expert team specializes in crafting cutting-edge software tailored to meet the unique needs of startups and established enterprises alike. From conceptualization to execution, we offer comprehensive services including web and mobile app development, UI/UX design, and ongoing software maintenance. Ready to elevate your business? Contact CyanicLab today and let us propel your vision to success with our top-notch IT solutions.
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxrickgrimesss22
Discover the essential features to incorporate in your Winzo clone app to boost business growth, enhance user engagement, and drive revenue. Learn how to create a compelling gaming experience that stands out in the competitive market.
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...Anthony Dahanne
Les Buildpacks existent depuis plus de 10 ans ! D’abord, ils étaient utilisés pour détecter et construire une application avant de la déployer sur certains PaaS. Ensuite, nous avons pu créer des images Docker (OCI) avec leur dernière génération, les Cloud Native Buildpacks (CNCF en incubation). Sont-ils une bonne alternative au Dockerfile ? Que sont les buildpacks Paketo ? Quelles communautés les soutiennent et comment ?
Venez le découvrir lors de cette session ignite
Software Engineering, Software Consulting, Tech Lead.
Spring Boot, Spring Cloud, Spring Core, Spring JDBC, Spring Security,
Spring Transaction, Spring MVC,
Log4j, REST/SOAP WEB-SERVICES.
Globus Connect Server Deep Dive - GlobusWorld 2024Globus
We explore the Globus Connect Server (GCS) architecture and experiment with advanced configuration options and use cases. This content is targeted at system administrators who are familiar with GCS and currently operate—or are planning to operate—broader deployments at their institution.
Providing Globus Services to Users of JASMIN for Environmental Data AnalysisGlobus
JASMIN is the UK’s high-performance data analysis platform for environmental science, operated by STFC on behalf of the UK Natural Environment Research Council (NERC). In addition to its role in hosting the CEDA Archive (NERC’s long-term repository for climate, atmospheric science & Earth observation data in the UK), JASMIN provides a collaborative platform to a community of around 2,000 scientists in the UK and beyond, providing nearly 400 environmental science projects with working space, compute resources and tools to facilitate their work. High-performance data transfer into and out of JASMIN has always been a key feature, with many scientists bringing model outputs from supercomputers elsewhere in the UK, to analyse against observational or other model data in the CEDA Archive. A growing number of JASMIN users are now realising the benefits of using the Globus service to provide reliable and efficient data movement and other tasks in this and other contexts. Further use cases involve long-distance (intercontinental) transfers to and from JASMIN, and collecting results from a mobile atmospheric radar system, pushing data to JASMIN via a lightweight Globus deployment. We provide details of how Globus fits into our current infrastructure, our experience of the recent migration to GCSv5.4, and of our interest in developing use of the wider ecosystem of Globus services for the benefit of our user community.
Enterprise Resource Planning System includes various modules that reduce any business's workload. Additionally, it organizes the workflows, which drives towards enhancing productivity. Here are a detailed explanation of the ERP modules. Going through the points will help you understand how the software is changing the work dynamics.
To know more details here: https://blogs.nyggs.com/nyggs/enterprise-resource-planning-erp-system-modules/
1. Agile Estimation for
Fixed Price Model
Challenges & Possible Solutions
Jayanthi Srinivasan
Linkedin: Jayanthi S, PMP,ITIL,PMI-ACP,SAFe SA
2. 2
About Me
PMP, ITIL, PMI-ACP, SAFE SA
Certified
More than 16 years in IT Industry
Specialized in
Agile Coaching
Assessment
Transformation
3. 3
Key Highlights
Context – Agile & Upfront Estimation in Fixed Price Model at Proposal Stage
Fixed Cost instead of Fixed Scope As a Solution
Implementation Challenges
Change Management Process
Fixed Cost instead of Fixed Scope as a Solution
Estimation Barriers
Recommended Sizing Techniques
Requirement Clarity Levels
Story Point Computing Approach
Definition of Done
Story Point Computing Models
First Velocity Computation
Velocity Decelerators & Accelerators
How do we arrive at Schedules?
Overall Agile Story Point Estimation and Planning Framework
Sample Estimation
How do we track the budget during project execution?
Conclusion
4. 4
Context – Agile & Upfront Estimation in
Fixed Price Model at Proposal Stage
Agile
Estimation
Progressive
Requireme
nts
No Team
Clarity
Fixed time,
Cost, Scope
Implications if not
considered
5. 5
Fixed Cost instead of Fixed Scope As a Solution
Fixed Price Model Challenges
Change Management - Fixed Cost
instead of Fixed Scope
Story Sizing Techniques
Story Point Computation Models
First Velocity as a Magic Number
Team
Size
Total
Effort
Schedule
Arrival
Budget
Tracking
6. 6
Implementation Challenges
The Agile Triangle
Reference:
http://2.bp.blogspot.com/x_mffEtfUTg/UQAz2HidX3I/AAAAAAAAAPY/gvkVuRRRZLI/s1600/Figure3.jpg
Limited Scope
Control
Frequent
Prioritization
More
Adaptable
Collaborative
Continuous
Delivery
7. 7
Change Management Process
Scrum Change Management Process
Reference: http://www.gregmester.com/wp-
content/uploads/2015/08/IterationPlanningChange.jpg
No changes during a sprint.
However Scrum framework allows
the Product Owner to add Change
Requests in the product backlog.
The Change Requests (story point
estimated) to be prioritized by
Product Owner.
The equivalent Story point user
stories are replaced and re-
prioritized.
8. 8
Fixed Cost instead of Fixed Scope as a Solution
Estimate by story points
with the initial set of
requirements.
Identify an approach
to compute the story
points and share the
approach with
customer and arrive at
a common
understanding.
Adapt for changes up
to the extent of
consumption of the
initially estimated story
points with some
buffer.
Beyond the initial
estimate of story
points, it can be
considered as
additional cost.
9. 9
Estimation Barriers
Cost Effort
No Actual Team
players at
Proposal Phase
Identifying the Right
Sizing Technique to
arrive at Story points
Requirement
clarity
Management
Release is the
first of its kind
(No previous
velocity)
10. 10
Recommended Sizing Techniques
Spikes
Story
UI Changes
DB changes
Test cases
Automation Scripts
CM / packaging
Task Breakdown
Story
Story 1 Story 2 Story 3
Story Splitting
Spike sample stories and
stack other stories
relative to those stories
Sizing Scales
T- Shirt
Fibonacci Series Team Conscience
Expert
Opinion
12. 12
Story Point Computing Approach
Define Done criteria
Define a Story Point Computing Model
Compute total Story points
Never convert Story Points to Efforts. It would be a very big disaster!
13. 13
Definition of Done
Story 1
Story 2
Story 3
Software with all features
work as defined by the user
story
All QA testing for
completed features is done
with no pending defects
Regression tests pass
All documentation is
completed
Planned stories
demonstrated to the Product
Owner, Customer and other
stakeholders
Story 1
Story 2
Story 3
Sample DoD
DoD can evolve Sprint on Sprint
based on the requirements and past
learnings
14. 14
Story Point Computing Model 1- Story
Point – Task Matrix
http://www.slideshare.net:80/MarrajuBollapRagada/estimating-story-points-in-agile-
magic-approach-47345114
The guidelines for each
complexity factor can be
pre-defined considering
clarity, technical, data and
functional complexities.
15. 15
Story Point Computing Model 2 – Effort Matrix
Sample Base Effort in Person Hours based on
multiple Technologies
Java .Net Oracle
XS 8 8 10
S 12 16 16
M 20 24 24
X 24 32 30
XL 30 48 40
Story point mapping from an effort range
Story Point Effort Range
1 0-10
2 10-20
3 20-40
5 40-60
8 60-100
13 >100
Epic Feature Story
Technology
Mapping Classification Effort Story Point
Epic 1 Feature 1 Story 1 .NET XL 48 5
Epic 1 Feature 1 Story 2 Java S 12 2
Epic 2 Feature 1 Story 1 .NET X 32 3
Epic 2 Feature 1 Story 2 Java X 16 2
Epic 2 Feature 2 Story 2 Oracle XS 10 1
Map Story Points from Complexity –Sample Effort Matrix
16. 16
First Velocity Computation
When there is no velocity data and no clue on the how the first
velocity would be, consider the first few stories planned for iteration.
Perform task breakdown for one story and compute the effort in hours. Similarly, few
more stories can be taken up till the first iteration effort is achieved.
Different combinations of Team Size and Velocity may be worked out and analyzed
17. 17
Velocity Decelerators & Accelerators
Velocity Decelerators (VD) - Sample
Item Factor Level
Team Expertise High – 0.98
Medium – 0.80
Low – 0.5
Project
Tools Availability High – 0.98
Medium – 0.80
Low – 0.5
Project
Product Owner
Availability &
Participation
High – 0.98
Medium – 0.80
Low – 0.5
Project
Requirement Clarity High – 0.98
Medium – 0.80
Low – 0.5
User Story
Velocity Accelerators (VA) - Sample
Item Factor Level
Common Components High – 1.5
Medium – 1.3
Low – 1.1
Project
Common Test Cases High – 1.5
Medium – 1.3
Low – 1.1
Project
Repeat Releases of the same
kind
High – 1.5
Medium – 1.3
Low – 1.1
Project
Velocity = V * VD * VA
Set up your own Velocity Accelerators and Decelerators
based on your project based experience and past learning
18. 18
How do we arrive at Schedules?
•First Velocity from one
scrum team
•Number of Scrum Teams
•Project Start Date
•Sprint Duration
•Total Story Points
Input
•Story Sizing Techniques
•Story Point Computation
Model
•Velocity Accelerators &
Decelerators
Tools &
Techniques •End Date of the Project
•Total Engineering Efforts
Output
19. 19
Overall Agile Story Point Estimation and Planning
Framework – Part I
Step# Steps Inputs Tools and Techniques Output
1
Product Backlog
creation/refinement
Initial Requirements Customer Workshops
Product Backlog (Initial)
BRD Dialogs
Use Cases Interviews
RFP
Functional
Decomposition
Product Backlog (from Customer) DEEP
Sample Product Backlog from Past
Projects
2
User Stories
Creation/refinement
Product Backlog
INVEST
Product Backlog with user
stories
BRD
Requirements Document
Sample User Stories from Past projects
3 Definition of Done
RFP
Checklist
DOD (Sprint and Release
levels)
Customer Dialog
Sample DOD from past projects
Defined Delvierables
List of Engineering Activities
NFRs
4
Prioritization and
Sequencing
Product Backlog with User Stories MoSCOW
Product Backlog with
Prioritization and
Sequence
Functional Flow Kano
ROI
Priority
Sequencing
Risk
20. 20
Overall Agile Story Point Estimation and
Planning Framework – Part II
Step# Steps Inputs Tools and Techniques Output
5
Story Sizing and Total Story
points computing
Product Backlog with
Prioritization and
Sequence Story Point Matrix
Product Backlog with
Story points
DOD (Sprint and Release
levels) Effort Correlation Matrix
Task Break Down
Approach
Spikes
6 Define Sprint length RFP
Customer Preference
Fixed Length of Sprint
Team Preference
Team Comfort
Coordination with
external parties
User Story Clarity
7
Effort & Story point of Initial set
of Stories
Product Backlog with
Prioritization and
Sequence Spikes Effort of each Story
DOD (Sprint and Release
levels) Task Break down Story point of each Story
Story Splitting
Team Conscience
Initial Set of Stories Expert Opinion
8
First Velocity from 1st Scrum
team
Initial Scrum team size
Cumulative Story Effort
Match with Single Sprint
Effort
Velocity = Cumulative
Story point count
Single Sprint Effort (Initial
team Size * Sprint Length)
Cumulative Story Point
Effort
21. 21
Overall Agile Story Point Estimation and Planning Framework
– Part III
Step# Steps Inputs
Tools and
Techniques Output
9 Compute Number of Sprints
FirstVelocity
Agile Estimation
Template
No. of Sprints
Total Story points
Sprint length
Additional Rework, Buffer, Release
Sprints
10
Additional Full time Efforts
Computation
Pre-Engineering Sprints length
Agile Estimation
Template
Additional Efforts
(Sprint 0/ Framework
Sprint/Regression)
Pre-Engineering Team Size
Time Box for each
Scrum Ceremony
Scrum Master Efforts
Effort for Additional
Meetings
Scrum of Scrum master Efforts
11
Effort for Additonal Partime
roles
Part Time Role Players (Agile
Coach, Architect etc)
Agile Estimation
Template
Additional Effort
Duration
12
Pre-Engineering Efforts
(Before the Engineering
Sprint duration)
Sprint zero Activities
Agile Estimation
Template
Additonal Effort
Duration
Team Size
22. 22
Step# Steps Inputs Tools and Techniques Output Template Mapping
13
Post Engineering
Efforts(After the
Engineering Sprint
duration)
Post Engineering Activities
(Performance Testing, Security
Testing etc)
Agile Estimation
Template
Additional Effort
Release Plan (Post
Engineering Additional
Efforts (in case of big
bang approaches)) - Sec 9
Duration
Team Size
14 Project Start Date
Pre-Engineering Duration Agile Estimation
Template
Revised Project Start Date
15 Project End Date
First Velocity First Velocity * N
Nearest Agreed End Date
= Project End Date
Release Plan (Arrive at
Schedules) - Sec 11
Velocity Accelerators
Accelerators (Common
Components, Same
team and release,
common test cases, etc) N = No. of Scrum Teams Velocity-Accl-Decel
Velocity Decelerators
Decelerators
(Requirement Clarity,
Team Comfort, Product
Owner Availability etc)
No. of Scrum Teams
Agile Estimation
Template
Engineering Start Date
Projected Leaves of Team Members
Holidays
Post Engineering Duration
16 Sprint Planning
Product Backlog
Agile Estimation
Template
Stories in each Sprint Sizing-Planning (Sprint #)
Computed Velocity
Story points for each Story
Sequence
17
Scrum Team
planning
Product Backlog
Agile Estimation
Template
Feature Based Team
Sizing-Planning (Scrum
Team #)
Computed Velocity
Story points for each Story
Sequence
Feature Mapping
Stories in each Sprint
Overall Agile Story Point Estimation and Planning Framework – Part IV
23. 23
Sample Estimation
Form First Scrum Team (without Scrum Master)
Compute First Velocity from First Scrum team
Normal – Without applying Velocity Accelerators and Decelerators
Applied– After applying Velocity Accelerators and Decelerators
Normal Applied
Total Story Points 385 385
First Scrum Team Size 5 5
First Velocity 43 22
Number of Scrum Teams 2 2
Story point per sprint (Velocity of Sprint) 86 44
Estimated # of Sprints 4.48 8.92
Estimation Buffer Sprints @ 15% 0.67 1.34
Rework Buffer Sprints @ 10% 0.45 0.89
Additions Buffer Sprints @ 10% 0.45 0.89
Pre-Release Sprint 1 1
Total Number of Sprints 7.0 13.0
Dev
Tester
Manual
Tester
Automation
BA Configuration UI
Team Size 3 2 1 1 0 1
Total Team Size 8
Sprint Duration 10 Days
Effort per Sprint 80 PD
560 PH
24. 24
Sample Estimation
Arrival of End Date
First Sprint Start Date 1-Nov-2015 1-Nov-2015
Sprint Duration 10 10
Last Sprint End Date 5-Feb-2016 29-Apr-2016
Compute Engineering Efforts
Engineering Team Size 10 10
Scrum Masters 1 1
Additional Roles 0 0
Team Size 11 11
Total Effort (in PD) based on Engineering 774.80 1434.93
Project Start Date 1-Feb-2016 18-Jan-2016
Project End date 30-May-2016 21-Oct-2016
Project Expected Duration
(months)
4.0 9.2
Arrive at Schedules
25. 25
How do we track the budget during project
execution?
• The change management process is by Fixed Cost
instead of Fixed
• Once the initial estimated Story points are
consumed, the Story points beyond this can be
considered as additional.
• The sources of story points may not be user stories
from initial requirements only. As the Sprint
execution progresses, Product Backlog gets added
with defects, Technical Debt and Change
Requests which also carry story points.
26. 26
How do we track the budget during project
execution? – Contd….
A sample way of tracking can be done as
follows:
Total number of User stories
planned = 100
Initial Story Points Estimated =
350
Sprint Duration = 2 weeks
Planned Velocity = 50
Expected Number of Sprints = 7
Delivered: Without CRs, defects, technical debt
Actual: With CRs/ defects/ technical debt
Customized Burn-up Charts
27. 27
Conclusion
Win-win solution of how Agile software development
projects can be executed in the fixed price model
proposed.
Fixed Cost instead of Fixed Scope way of execution has
been the main highlight.
To achieve this, the different hurdles like Requirement
clarity, Story Sizing, Story point computation models, First
time velocity and a customized Budget tracking
mechanisms have been shared.
This overcomes the upfront Estimation challenges and
also an efficient method of arriving at Story points during
the proposal stage has been provided.
28. 28
Head of Agile & DevOps Practice in a
Top BFSI company
More than 20 years in IT Industry
Agile Evangelist
Agile Coaching, Transformation,
Implementation
KV Sharma
[LinkedIn: KV Sharma]
I Acknowledge…..
For reviewing, enabling and contributing ………….