Practical Agile Analytics: Reduce uncertainty and stop making such a big deal...Steven J. Peters, PhD
These slides focus on analyzing user story size estimates of and actual task hours scrum teams to gauge the uncertainty around those estimates. An approach is suggested for reducing uncertainty and improving user story size estimation accuracy.
Part II: Planning Time: Determining When and How MuchMuzo Bacan
Project assignments always have deadlines. So even though we’re not sure what our new project is supposed to accomplish, we want to know when it has to be finished.
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;
Practical Agile Analytics: Reduce uncertainty and stop making such a big deal...Steven J. Peters, PhD
These slides focus on analyzing user story size estimates of and actual task hours scrum teams to gauge the uncertainty around those estimates. An approach is suggested for reducing uncertainty and improving user story size estimation accuracy.
Part II: Planning Time: Determining When and How MuchMuzo Bacan
Project assignments always have deadlines. So even though we’re not sure what our new project is supposed to accomplish, we want to know when it has to be finished.
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;
Doing agile with an ISO-20000 Telco (AgilePT 2015)Manuel Padilha
A story from the trenches regarding a software project developed for a Telco company. The challenges faced while dealing with a mostly Agile customer that is part of a larger company with heavily defined processes.
The "way out" and how to deliver working software with close to zero spec and still complying to project management requirements, customer timings and own company budget.
Kanban vs Scrum: What's the difference, and which should you use?Arun Kumar
Originally presented at the 207 Lean Transformation Conference, this presentation provides a practical introduction to Scrum, particularly for public sector employees, and guides you to deciding whether Kanban or Scrum will work best for your teams and projects.
Velocity is perhaps the most useful metric available to agile teams. In this session we will look at advanced uses of velocity for planning under special but common circumstances. We will see how to forecast velocity in the complete absence of any historical data. We will look at how a new team can forecast velocity by looking at other teams. We will see how to predict the velocity of a team that will grow or shrink in size. Most importantly we will look at the use of confidence intervals to create plans we can be 90% confident in, even on fixed-price or fixed-date contracts.
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.
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!
“Doing Agile is just a first step; being agile needs to have a totally different mindset, and multidimensional perspectives.”
― Pearl Zhu, Digital Agility: The Rocky Road from Doing Agile to Being Agile
5 must have add ons to power up your orangescrum community versionOrangescrum
Orangescrum community add-ons are specially designed to add structure to your projects and provide clear insights to manage team and enhance productivity at workplace. http://blog.orangescrum.com/
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
KPI Calculus for BSC Performance & Progress EstimationFarooq Omar
In the business space, a marker is a mathematical worth that is connected to some sort of cycle or business objective.
Its essential objective is to show a number that can give us a thought regarding the current presentation of the processor's business objective.
Addressing the inquiry concerning driving execution, it is right to state that driving presentation is handled into the slacking execution for a situation when the theory that remains behind the objective ends up being valid.
A more secure option for the KPI expression would be "pointer" or "metric."
Laimonas Lileika — Hybrid Project Management: Excellence Behind a BuzzwordAgileLAB
Laimonas Lileika will encourage you to unleash your Project Management creativity by combining Agile and Waterfall paradigms.
This speech is for you if you are interested in:
- Importance of Context in Project Management;
- Most frequent misperceptions about Agile and Waterfall models;
- Pragmatic approach to project management: how to make a hybrid work in real.
Doing agile with an ISO-20000 Telco (AgilePT 2015)Manuel Padilha
A story from the trenches regarding a software project developed for a Telco company. The challenges faced while dealing with a mostly Agile customer that is part of a larger company with heavily defined processes.
The "way out" and how to deliver working software with close to zero spec and still complying to project management requirements, customer timings and own company budget.
Kanban vs Scrum: What's the difference, and which should you use?Arun Kumar
Originally presented at the 207 Lean Transformation Conference, this presentation provides a practical introduction to Scrum, particularly for public sector employees, and guides you to deciding whether Kanban or Scrum will work best for your teams and projects.
Velocity is perhaps the most useful metric available to agile teams. In this session we will look at advanced uses of velocity for planning under special but common circumstances. We will see how to forecast velocity in the complete absence of any historical data. We will look at how a new team can forecast velocity by looking at other teams. We will see how to predict the velocity of a team that will grow or shrink in size. Most importantly we will look at the use of confidence intervals to create plans we can be 90% confident in, even on fixed-price or fixed-date contracts.
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.
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!
“Doing Agile is just a first step; being agile needs to have a totally different mindset, and multidimensional perspectives.”
― Pearl Zhu, Digital Agility: The Rocky Road from Doing Agile to Being Agile
5 must have add ons to power up your orangescrum community versionOrangescrum
Orangescrum community add-ons are specially designed to add structure to your projects and provide clear insights to manage team and enhance productivity at workplace. http://blog.orangescrum.com/
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
KPI Calculus for BSC Performance & Progress EstimationFarooq Omar
In the business space, a marker is a mathematical worth that is connected to some sort of cycle or business objective.
Its essential objective is to show a number that can give us a thought regarding the current presentation of the processor's business objective.
Addressing the inquiry concerning driving execution, it is right to state that driving presentation is handled into the slacking execution for a situation when the theory that remains behind the objective ends up being valid.
A more secure option for the KPI expression would be "pointer" or "metric."
Laimonas Lileika — Hybrid Project Management: Excellence Behind a BuzzwordAgileLAB
Laimonas Lileika will encourage you to unleash your Project Management creativity by combining Agile and Waterfall paradigms.
This speech is for you if you are interested in:
- Importance of Context in Project Management;
- Most frequent misperceptions about Agile and Waterfall models;
- Pragmatic approach to project management: how to make a hybrid work in real.
Webinar: Development with Agile, Waterfall and Agile-Waterfall HybridIntland Software GmbH
Watch this webinar recording to learn about the fundamentals of Waterfall and Agile development, as well as the “Agifall” Hybrid solution that aims to combine the benefits of both approaches. After introducing both approaches, this webinar discusses the two most widely used Agile methodologies: Scrum and Kanban. Through a live demonstration, the webinar also shows you how to manage projects with either of these development frameworks in codeBeamer.
http://intland.com/webinar/2015-03/development-with-agile-waterfall-and-agile-waterfall-hybrid-2/
Here is a presentation I presented to management describing how waterfall transitions into scrum. Couldn’t have been done without slideshare.com slides. This is me giving back.
16 Popular Project Management Methodologies (Infographic)Wrike
https://www.wrike.com/blog/09/29/2014/Project-Management-Methodologies-Infographic - We cover 16 popular project management methodologies by distilling the essentials into an infographic that's easy to reference and share with colleagues.
Whether you're new to Project Management, or simply want to review options for your next project, check out our crash course in PM methods.
For more on project management basics, check out our ultimate guide to PM: https://www.wrike.com/blog/09/16/2014/The-Ultimate-Project-Management-Guide
A Beginner's Guide to IT Project ManagementWorkfront
“What is IT project management?” The simple answer is those efforts involved with managing the processes and activities associated with ensuring the success of IT projects or systems management-related responsibilities. But to more fully understand what is at the heart of IT project management, it helps to consider a few more questions…
Agifall - Combining Waterfall and Agile Development Process for Digital and S...Mark Fromson
We all know waterfall has generally fallen out of favour and agile is the new process wunderkind. However, is pure agile really appropriate, or even possible, for the majority of our current digital projects? If the technical team is driving the agile development process from the start, just how and when do we integrate the user experience and creative contribution into the project lifecycle? Does agile really mean development first with no upfront design or specification, or, is there a better way to make agile development more effective when it begins? Certainly agile can be problematic for client projects when the statement of work contract is king for establishing project scope ahead of time. So how do we successfully integrate the benefits of agile into client-vendor engagements without putting either party at risk? This presentation topic is on how to effectively combine the best of waterfall and agile into a hybrid process model called “Agifall.” No process is perfect, but Agifall just might be the one that works best for your next project.
Our latest webinar "Software Development with Agile Waterfall Hybrid Method" presents you the pros and cons of both methodologies, Agile and Waterfall.
Watch our webinar to learn more about what kind of projects the Hybrid model works for best, and how exactly you can implement a Hybrid approch in software development and benefit from the advanced features of codeBeamer ALM software.
User Experience Design: The Past, The Present, The FutureCharbel Zeaiter
In our mostly true exploration of the history of UX and the current space we're in, we look to how UX Designers will be called upon in the future to create experiences that matter.
PMBOK fifth edition data flow diagram by englishKose Jumnichi
Develop Project Management Plan Data Flow Diagram.
Almost processes are topological sorted.
This figure is drawn with a vertical line "the new data model"
(work performance data / infomation / reports,and "Change requests").
One page of PMBOK5 edition Data flow Diagrams by Japanease Broked english.
PMBOK6 editions is heare https://www.slideshare.net/kosejumnichi/pmbok-six-editiondataflow-diagram-by-english-a3-printable
THERE'S A NEW VERSION AVAILABLE: https://www.slideshare.net/ricardo.vargas/pmbok-guide-processes-flow-6th-edition
The 47 processes are separated into colors according to their respective knowledge areas. Only the main connections that are depicted in the PMBOK® Guide are shown in this process flow.
PMBOK® Guide 5th edition Processes Flow in English - Simplified VersionRicardo Viana Vargas
THERE'S A NEW VERSION AVAILABLE: https://www.slideshare.net/ricardo.vargas/pmbok-guide-processes-flow-6th-edition-simplified-version
In this simplified version of the PMBOK® Guide 5th edition Processes Flow only the 47 processes names are show, without their inputs, tools and techniques and outputs.
Andreas Tschas - Pioneers - Building Startup Marketplaces in Europe & Asia - ...Burton Lee
Talk by Andreas Tschas, CEO & Co-Founder, Pioneers Festival, at Stanford on Feb 22 2016, in our session on 'Startup Marketplaces & AI FinTech Founders :: Vienna & Portugal'.
Website: http://www.StanfordEuropreneurs.org
YouTube Channel: https://www.youtube.com/user/StanfordEuropreneurs
Twitter: @Europreneurs
Why Our Inbound Marketing Agency went "All In" with AgileDechay Watts
An agile approach to inbound marketing (or any marketing plan) eliminates the old school method of forcing deliverables that lock marketers and their clients into premature decisions. Typically, these decisions are outlined in the very beginning of the relationship, when we knew each other the least, which just doesn't make sense.
Agile lets us all move away from set-it-and-forget-it assumptions in contracts that quickly become outdated. It also lets our team of inbound experts use their honed skill set and proactively advise clients on the strategic deliverables that will get the best results every month. Agile provides a structure that drives marketers to be:
Faster creators
Better testers
More flexible
Customer-centered
Focused on priorities of high-value
Story points vs hours choose wisely; turn the bane of project estimation into...Katy Slemon
This blog covers the difference between Story Points vs Hours for Agile Estimation. Read why Bacancy uses traditional hours over story points, how it’s helpful
7. and they wanted to switch to
Scrum... at least, some of
them did.
8. “You can use ‘scum’ or whatever you
want. Just give me a Gantt chart, tell
me what day you will be done all the
work and how much it will cost.”
9. Here’s the rub...
Dir. of IT/Product Owner wants a fresh start,
embracing change and believes deeply in the
benefits of Scrum
Senior Mgmt./Project Sponsor wants results, but
is not interested in changing how the company
looks at work
We needed to find a way to keep both sides
happy so we could get the work done.
10. the not helping part...
Sr. Sponsor: When will it be done?
Product Owner: When you stop asking for more
stuff.
Sr. Sponsor: What will you have ready for me on
Date X?
Product Owner - Whatever we’ve got completed
at that time
11. How we solved it...
Both the Tech Lead and PM assigned were CSMs
1 CSM to lead development
1 CSM to manage communication and
relationship with senior management
Tailoring of the output of the Scrum Process for an
audience looking for more traditional PM
reporting
12. Project Leadership
Product Owner - storehouse of knowledge of what the
application is supposed to do and how it was done
before
Scrum Master - traditional CSM role...leads scrum
efforts, manages technical team’s efforts
PM/Scrum Master - acts as the “anti-corruption layer”
between senior sponsor and product owner, translates
sprint reporting into something palatable by senior
management
13. Why do they want what they
want?
There is the “thing” being demanded
There is the reason it is being demanded
If you can’t meet the demand, meet the
motivation
Uncovering why they need what they are asking
for can create options for meeting their true
need instead of their demand
14. Want - Need
They want a Gantt chart with milestones, cost estimates,
staffing requirements
They need to be able to demonstrate to the organization
that the project is on track and moving in a positive
manner towards completion
A lack of visibility can appear as chaos to those who are
already worried. This drives fear, which drives stress
Stress is way bad
Scrum offered a level of transparency that was ideally
suited to this situation... except for one thing
15. The one thing...
Senior Management did not have the bandwidth to
attend the daily stand-ups or visit the war room or get
involved with the project at a participant level
Senior Management just needed information that they
could trust and they needed it provided with minimal
effort required of them
16. Care and feeding...
While Senior Management was asking for traditional
reporting, what they really wanted was a clear picture,
week to week, of how the work was progressing and
some reassurance that we could meet the deadline
Option 1: Develop a best guess Gantt Chart that would
be based only on the initial estimates provided by the
Product Owner and hope we’d be able to keep pace
with it.
Option 2: Use the output of the Scrum process to build
a story, sprint by sprint, that earned trust repeatedly by
showing concrete examples of output and progress
17. Getting Started with Option 2
We began the project with a backlog of all
functionality to be provided in the deliverable.
The product owner provided the team with complexity
estimates on each item to be delivered and had
converted those into time estimates as well.
The product owner assumed no reusability for the
components to be produced, working under the
assumption that this would provide some padding in
the schedule.
18. Working Time
While there were some staffing fluctuations across the
life of the project, we began with the assumption that
we could expect to see an average of six hours of
productivity, per day for each resource working on the
project. We also assumed that each of them would
work five days per week.
19. Planning the Sprint
During Sprint planning meetings, we worked with
our ideal hour of labor for that sprint and added
items, based on prioritization. Each item would be
estimated for both complexity and labor required to
complete.
We added only enough work to fill the number of
available hours per sprint
Because work on the use cases was just beginning at
the start of the project, the team had to rely on the
product owner to understand the requirements for
each deliverable item
20. Watching the Variance
At the start of each sprint we had a set list of tasks
for the team to work on.
We had complexity estimates and labor estimates for
each task provided by both the Product Owner and
the Development Team.
We began tracking the variance, sprint to sprint
between available hours and actuals and between
planned hours and actuals
We also began tracking the variance between the
original estimates and team estimates for both
complexity and labor required to complete.
21. The slightly educated guess
By tracking the variance in Fibonacci estimation
across sprints, we determined that the original
estimates for complexity were, on average, 155%
of what the team estimated for the same work.
By tracking the variance in labor estimation across
sprints, we determined that the original estimates
for labor were 125% of what the team estimated
for the same work.
22. The slightly educated guess
In order to get closer to an understanding of when the
project was likely to actually end, based on what we
knew about the deliverables we had to provide, we
applied the 3 Point Pert Estimation formula:
Optimistic + Most Likely + Pessimistic
3
23. 3 Point Pert Application
While not an entirely proper use of the formula, it
provided a more likely estimate than just using one of
the three:
Pessimistic: Original Labor Estimate
Most Likely: Original Labor Estimate/Labor
Estimation Variance
Optimistic: Original Labor Estimate/Fibonacci
Estimation Variance
25. Working with the educated
estimate
With an established labor capacity (# of team members
* 6 hours/day * 5 days/week) and a revised estimate on
how many hours of labor we expect to actually have to
complete, we can determine how long it will take to
get through the backlog.
4 team members * 6 hours/day * 5 hours/week = ideal
work capacity of 120 hours per week
26. Applying capacity to the Pert
Estimate
With an ideal capacity of 120 hours of labor per
week
And an estimated 815 hours of labor to burn down
The project should take 6.8 weeks to complete
27. Tracking Performance
By tracking the team’s actuals against their
planned work, we were able to determine, on
average, how effective they were at reaching their
goal each week.
If we know the team is planning for 120 hours of
work per week, but, on average, they only
complete 90% of that work, we can make
adjustments to how we report on the burndown.
28. Tracking Performance
120 hours/wk * 90% = 108 actual performed
hours realized per week
If we are three weeks into our 815 hour project,
we will have realized 324 hours of work instead
of our expected 360 hours of work
This leaves us with 491 hours of work remaining
after week three
29. Tracking Performance
Given that we are realizing only 324 hours/week,
we have to adjust expectations with the client
because the remaining 491 hours will now take
longer than originally expected
491/108 = 4.5 weeks will be required to complete
the remaining work as opposed to the 4 weeks it
would take if we were performing at 120 hours as
planned
30. Tracking Performance
At the end of each sprint, adjustments were made
to all of the previous calculations based on new
performance data, as well as any new items added
to the backlog.
These adjustments to the estimates keep the
reporting as near to real time as possible and it
goes a long way with respect to demonstrating the
value provided of this type of reporting over the
originally request Gantt chart.
31. Keeping It Real
You need to re-evaluate the variances and update the
forecasting based on revised averages which include the
new performance data at the end of each sprint and
report on this, showing how it trends as the work
progresses
This not only helps you re-evaluate the total work
remaining each Sprint it build a story for Sr.
Management that can show positive or negative trends
The story that is created through this type of reporting is
what “sells” the value to Sr. Management
32. Wrapping it up for the folks
upstairs...
No matter how much information you have
on work performed, or work remaining, it is
only as good as your ability to communicate
it to the parties who need to be able to digest
it
33. One Report to Bind It All
The weekly report to management
Summary Page of Issues/Accomplishments
Summary Table of Performance Data
Trend and Completion Information
Breakdown of recorded man hours worked
and cost of those hours
(if these can be tracked against an original set budget, even better)
34. Example of a the Summary
Table of Performance Data
Project Development Summary
Week Ending 7/25/08
Estimated Total Man Hours of Work Available 3118
Total of Actual Man Hours Worked To Date 1018
Percent of Total Man Hours Worked To Date 33%
Hours of Work Completed in Sprint Ending (7/25/08) 87
Hours of Work Planned for Sprint Ending (7/25/08) 94
Percent of Work Completed to Work Planned 93%
Percent of Work Completed to Work Planned Last Sprint 97%
Velocity Change Since Last Week -4%
Estimated Hours of Available Work Remaining 1620
Hours of Development Work Not Yet Done Done 2009
Average Estimation Accuracy (Original vs. Developer) for Open Development Work 145%
Adjusted Number of Development Hours Remaining 2922
Adjusted Remaining Development Work - Remaining Available Work 1302
Weeks off based on Variance (with 150 wk Man Hours) 8.68
35. Additional Data Points
We also track the following on a Sprint to
Sprint basis:
Targeted (ideal) hours vs. Actual Hours
Achieved
Hours Achieved vs. Hours Planned
We report on these each week to show trends
here as well
37. What’s Missing
The Summary and Trend Analysis is a great
starting place and provides excellent detail that
you can use to measure progress, similar to earned
value
But there is an easier way...
44. Summary
You can use Scrum in a Waterfall Environment, even if the
environment will not be converted
It may work best with a pair of scrum masters, one for the team
and one for management
Understanding the needs of management, not just what they
demand is the key to your success
You need to tailor the information you provide them with to
meet their needs. If Scrum does not give them what they want,
take what Scrum give you and translate it into something they
can digest
Management likes Pie