Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Project Management

Own the Future of Management, with Me

NOOP.NL - Jurgen Appelo - Sun, 03/26/2017 - 16:53
You have just 5 days left to become my business partner.

Since today, I am no longer the only owner of the Management 3.0 business. I have co-owners. Yay!! And you can now join me as a co-owner too.

Management 3.0 is about better management with fewer managers. The ideas and practices help leaders and other change agents with managing for more happiness at work. And the brand was named the leader of the Third Wave of Agile, because of our focus on the entire business, rather than just on development practices and projects. By improving the management of organizations, we hope we are helping to make the world a better place.

As a co-owner of Management 3.0, you support and participate in my adventure. Either passively or actively, you help our team to offer healthy games, tools, and practices to more managers in more organizations.

Since last week, a Foundation owns the Management 3.0 business model and this Foundation has issued virtual shares. The business has grown by more than 40% each year in 2014, 2015, and 2016. In other words, the ownership of shares not only contributes to happier people in healthier organizations. It is also a smart business investment!

Until 31 March 2017, I sell virtual shares (officially: certificates) for EUR 50 per share. On 1 April 2017, I stop selling them for a while. I may continue selling more shares later, but probably at a higher price. And there are more reasons not to wait!

When you buy 10 or more shares before 1 April 2017, I send you a free copy of the book Managing for Happiness, personally signed by me on a unique hand-drawn bookplate.

When you buy 100 or more shares before 1 April 2017, you are entitled to a free one-hour keynote on location (excluding travel and accommodation expenses).

When you buy 1,000 or more shares before 1 April 2017, you gain the status of honored business partner, with special privileges and exclusive access to the team and me.

And everyone who buys shares has a chance to win one of my last eight copies of #Workout, the exclusive Limited Edition. Some people sell it for $2000+ on Amazon.

It is important to known that Management 3.0 is a global brand. I prefer that ownership is distributed across the world. I reserve the right not to sell too many shares to people in the same country. (And yes, it’s first come, first served.)

What are the next steps?

1. Check out my FAQ for all details (read it here);
2. Fill out the application form (APPLY HERE);
3. Sign the simple agreement (I will send it);
4. Pay the share price (information will follow).

I asked the notary and my accountant to make it so simple that it’s five minutes of work and you could be co-owner in one day.

When this simple procedure is complete, we add you to the exclusive list of Management 3.0 owners. You can proudly wear a bragging badge on your website, and the team will inform you about new developments on a regular basis.

Don’t wait too long!

This offer is valid until 31 March 2017. The available shares per country are limited.

OWN THE FUTURE OF MANAGEMENT – APPLY NOW

The post Own the Future of Management, with Me appeared first on NOOP.NL.

Categories: Project Management

Estimating Accuracy Mathematics

Herding Cats - Glen Alleman - Fri, 03/24/2017 - 01:55

In the estimating business, like many things in project management, there is confusion about principles, practices, and processes. And sometimes even outright misinformation. 

Here's an example used by the #NoEstimates advocates. Starting in 1986, there is a sentence that says more or less what the slide says below.

A good estimation approach should provide estimates that are within 25% of the actual results, 75% of the time

The book this statement comes from is Conte, S. D., H. E. Dunsmore and V.Y. Shen. Software Engineering Metrics and Models. Menlo Park CA: The Benjamin/Cummings Publishing Company, Inc., 1986. Looking at the statement is on page 172-175 open on my desk right now. Steve McConnell abstracted the original page content into those words. 

 

C7mfWBCW0AEB33Z

And the words on page 172 to 175 speak about the Magnitude and Mean Magnitude of relative Error. The term within 25% is the Mean Relative Error, that is the estimate is within 25% of the actual value - the real value compared to the estimated value.

So if the actual value - after we are done - is $25,000 then is the estimate is within 25% of that estimate - $18,700 - then that's a good start.

Screen Shot 2017-03-23 at 8.44.03 AMIn other words, if the error of our estimate is less that 25% of the actual outcome, 75% of the time, we're doing pretty well early in the project - possibly on day one. In our NASA Software Intensive System of Systems business, we need an 80% confidence basis of estimate in the proposal - A 20% MRE. Conte, Dunsmore, and Shen's number is a 75% confidence level in 1986.

We use Monte Carlo Simulation tools and Method of Moments algorithms from very large historical - the holy grail of empirical forecasting - databases and apply analogous and parametric models for work that is new to get these numbers.

The notion used by #NoEstinates advocates does NOT mean that the estimate is within 25% of the actual. But the Mean Relative Error of the estimate is with within 25%. They would know that if the Read the Book and stopped echoing someone else's poorly translated mathematics.

This is a serious error in understanding the principles of estimating, and this error is repeated throughout the #NoEstimates community. It's time to put it right. 

Please go buy Software Engineering Metrics and Models, it's cheap and packed full of the mathematics needed to actually perform credible estimating on software intensive systems. And download the paper that followed "A Software Metrics Survey." While you're at it buy Estimating Software Intensive System of Systems and you to can start debunking the #NoEstimates hoax that Decisions can be made in the presence of uncertainty without estimating the impact of those decisions.

The only way this can happen is if there is no uncertainty, the future is like the past, there is no risk - reducible or irreducible and nothing changes. 
 

 

 

Related articles Risk Management is How Adults Manage Projects Information Technology Estimating Quality Herding Cats: The Fallacy of Wild Numbers Herding Cats: Quote of the Day Want To Learn How To Estimate? Two Books in the Spectrum of Software Development Essential Reading List for Managing Other People's Money What Happened to our Basic Math Skills? The Fallacy of the Planning Fallacy
Categories: Project Management

Estimating Accuracy Mathematics

Herding Cats - Glen Alleman - Thu, 03/23/2017 - 16:03

In the estimating business, like many things in project management, there is confusion about principles, practices, and processes. And sometimes even outright misinformation. 

Here's an example used by the #NoEstimates advocates. Starting in 1986, there is a sentence that says more or less what the slide says below

A good estimation approach should provide estimates that are within 25% of the actual results, 75% of the time

The book this statement comes from is Conte, S. D., H. E. Dunsmore and V.Y. Shen. Software Engineering Metrics and Models. Menlo Park CA: The Benjamin/Cummings Publishing Company, Inc., 1986. Looking at the statement is on page 172-175 open on my desk right now. Steve McConnell abstracted the original page content into those words. 

 

C7mfWBCW0AEB33Z

And the words on page 172 to 175 speak about the Magnitude and Mean Magnitude of relative Error. The term within 25% is the Mean Relative Error, that is the estimate is within 25% of the actual value - the real value compared to the estimated value.

So if the actual value - after we are done - is $25,000 then is the estimate is within 25% of that estimate - $18,700 - then that's a good start.

Screen Shot 2017-03-23 at 8.44.03 AMIn other words, if the error of our estimate is less that 25% of the actual outcome, 75% of the time, we're doing pretty well early in the project - possibly on day one. In our NASA Software Intensive System of Systems business, we need an 80% confidence basis of estimate in the proposal - A 20% MRE. Conte, Dunsmore, and Shen's number is a 75% confidence level in 1986.

We use Monte Carlo Simulation tools and Method of Moments algorithms from very large historical - the holy grail of empirical forecasting - databases and apply analogous and parametric models for work that is new to get these numbers.

The notion used by #NoEstinates advocates does NOT mean that the estimate is within 25% of the actual. But the Mean Relative Error of the estimate is with within 25%. They would know that if the Read the Book and stopped echoing someone else's poorly translated mathematics.

This is a serious error in understanding the principles of estimating, and this error is repeated throughout the #NoEstimates community. It's time to put it right. 

Please go buy Software Engineering Metrics and Models, it's cheap and packed full of the mathematics needed to actually perform credible estimating on software intensive systems. And download the paper that followed "A Software Metrics Survey." While you're at it buy Estimating Software Intensive System of Systems and you to can start debunking the #NoEstimates hoax that Decisions can be made in the presence of uncertainty without estimating the impact of those decisions.

 

 

 

Related articles Risk Management is How Adults Manage Projects Information Technology Estimating Quality Herding Cats: The Fallacy of Wild Numbers Herding Cats: Quote of the Day Want To Learn How To Estimate? Two Books in the Spectrum of Software Development Essential Reading List for Managing Other People's Money What Happened to our Basic Math Skills? The Fallacy of the Planning Fallacy
Categories: Project Management

Doors Now Open to the Better User Stories Advanced Video Training

Mike Cohn's Blog - Wed, 03/22/2017 - 13:05

This past week we’ve given away free online training and a number of resources to help you combat some of the most vexing problems agile teams encounter when writing user stories.

Now it’s time to open the doors to the full course: Better User Stories.

“In my 30 years of IT experience, this class has without question provided the most ‘bang for buck’ of any previous training course I have ever attended. If you or your organization are struggling with user stories, then this class is absolutely a must have. I simply can’t recommend it enough. 5 Stars!!” - Douglas Tooley

If you watched and enjoyed the free videos, you’ll love Better User Stories. It’s much more in-depth, with 9 modules of advanced training, worksheets, lesson transcripts, audio recordings, bonus materials, and quizzes to help cement the learning.

Registration for Better User Stories will only be open for one week

Click here to read more about the course and reserve your seat.

Because of the intense level of interest in this course, we’re expecting a large numbers of people to sign-up. That’s why we’re only opening the doors for one week, so that we have the time and resources to get everyone settled.

If demand is even higher than we expect, we may close the doors early, so if you already know you’re interested, the next step is to:

Choose one of 3 levels of access. Which is right for you?

I know when it comes to training, everyone has different needs, objectives, learning preferences and budgets.

That’s why you can choose from 3 levels of access when you register:

  • Professional - Get the full course with lifetime access to all materials and any future upgrades
  • Expert Access - Acquire the full course and become part of the Better User Stories online community, where you can discuss ideas, share tips and submit questions to live Q+A calls with Mike
  • Work With Mike - Secure all of the above, plus private, 1:1 time with Mike to work through any specific issues or challenges.

Click here to choose the best level for your situation

What people are already saying

We recently finished a beta launch where a number of agilists worked through all 9 modules, providing feedback along the way. This let us tweak, polish and finish the course to make it even more practical and valuable.

Here’s what people had to say:

Anne Aaroe

Thank you for an amazing course. Better User Stories is by far the best course I have had since I started my agile journey back in 2008.

Anne Aaroe

Packed full of humor, stories, and exercises the course is easy to take at one’s own leisure. Mike Cohn has a way of covering complex topics such as splitting user stories with easy to understand acronyms, charts and reinforces these concepts with quizzes and homework that really bring the learning objectives to life. So, whether you’re practicing scrum or just looking to learn more about user stories this course will provide you the roadmap needed to improve at any experience level, at a cost that everyone can appreciate.

Aaron Corcoran

Click here to read a full description of the course, and what you get with each of the 3 levels of access. Questions about the course?

Let me know in the comments below.

Quote of the Day

Herding Cats - Glen Alleman - Tue, 03/21/2017 - 22:43

“The real value of computers is communication, not computation.”
- Natasha Kalatin

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Tue, 03/21/2017 - 22:43

“The real value of computers is communication, not computation.”
- Natasha Kalatin

Categories: Project Management

How to Add the Right Amount of Detail to User Stories

Mike Cohn's Blog - Tue, 03/21/2017 - 13:00

Today’s post introduces the third installment in a free series of training videos all about user stories. Available for a limited time only, you can watch all released videos by signing up to the Better User Stories Mini-Course. Already signed up? Check your inbox for a link to the latest video, or continue reading to find out about today’s lesson.

An extremely common problem with user stories is including the right amount of detail.

If you include too much detail in user stories this makes story writing take longer than it would otherwise. As with so many activities in the business world, we want to guard against spending more time on something than necessary.

Also, spending time adding too much detail leads to slower development as tasks like design, coding, and testing do not start until the details have been added. This delay also means it takes longer for the team and its product owner to get feedback from users and stakeholders.

But adding too little detail can lead to different but equally frustrating problems. Leave out detail and the team may struggle to fully implement a story during a sprint as they instead spend time seeking answers.

With too little detail, there’s also an increased chance the development team will go astray on a story by filling in the gaps with what they think is needed rather than asking for clarification.

There’s danger on both sides.

But, when you discover how much detail to add to your stories, it’s like Goldilocks finding the perfect bowl of porridge. Not too much, not too little, but just right.

But how do you discover how much is the right amount?

You can learn how in a new, 13-minute free video training I’ve just released. It’s part of the Better User Stories Mini-Course. To watch the free video, simply sign up here and you’ll get instant access.

Remember, if you’ve already signed up to the course you don’t need to sign in again, just go to www.betteruserstories.com and video #3 will already be unlocked for you.

Adding the right amount of detail--not too much, not too little--is one of the best ways to improve how your team works with user stories. I’m confident this new video will help.

Mike

P.S. This video is only going to be available for a very short period. I encourage you to watch it now at www.betteruserstories.com.

Quote of the Day

Herding Cats - Glen Alleman - Mon, 03/20/2017 - 15:44

You can sway a thousand men by appealing to their prejudices quicker than you can convince one man by logic. – Robert A. Heinlein, Revolt in 2100

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Mon, 03/20/2017 - 15:44

You can sway a thousand men by appealing to their prejudices quicker than you can convince one man by logic. – Robert A. Heinlein, Revolt in 2100

Categories: Project Management

Software Development Linkopedia March 2017

From the Editor of Methods & Tools - Mon, 03/20/2017 - 14:25
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about sharing information, team conflicts, leadership, meetings, DevOps, test management, refactoring software architecture, pair testing, software design and scaling Agile. Text: How I Share Information with my Team Text: Helping Teams […]

Where is the Adult Supervision on this Program?

Herding Cats - Glen Alleman - Mon, 03/20/2017 - 01:34

Most programs I work are in trouble in some form - other wise they would not have hired us to help. 

One quote we use to describe these situations is

What's the difference between this program and the Boy Scouts? The Boy Scouts have adult supervision.

But today I sat through an out brief from a government auditing agency on a $10B program and one of my colleagues made this statement

This program is like a house with 4 teenage boys, where the parents went on vacation and never returned.

When we encounter these situations, it is tempting to start providing solutions. This is a serious mistake unless we have done the Root Cause Analysis of the observed problem. It may turn out what is being observed is the symptom of a root cause that was not understood by the people that hired us.

This is a rookie mistake in the process improvement business. I see it all the time. Some self-proclaimed thought leader pontificates on what is wrong with the software industry. Makes blanket statements like the current software development methods have not made much difference in the general success in the software development - the software crisis. That is according to the much debunked Standish Reports.

The charts showing software project failures, challenged or otherwise, never seem to have a root cause of the failure or less than desired performance. Same is the case with those advocating that the Cone of Uncertainty doesn't match how the work proceeds on their projects. 

Why? Why are you seeing what you're seeing? What are the possible causes of these observations?

Like most voices pointing out obvious difficulties in writing software for money, without identifying the Root Cause, the proposed solutions have no basis for testing their fix will actually fix anything. 

Most of the time when we come onboard to put the project back on track, we find missing processes, missing data produced from those processes, and most of the time people behaving badly. Now you could make the case that it starts with the people. Which is a noble conjecture and could possibly be true. 

But the naive notion that people can operate on a non-trivial in the absence of a process is just that - naive. 

One place to start is Identifying Acquisition Framing Assumptions Through Structured Deliberation 

Related articles Estimating and Making Decisions in Presence of Uncertainty The Dysfunctional Approach to Using "5 Whys" Managing in Presence of Uncertainty Herding Cats: Cone of Uncertainty - Part Cinq (Updated) Five Estimating Pathologies and Their Corrective Actions Are Estimates Really The Smell of Dysfunction? Estimating Probabilistic Outcomes? Of Course We Can! Herding Cats: Software Development for the 21st Century
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sun, 03/19/2017 - 01:55

Insight, untested and unsupported, is an insufficient guarantee of truth. - Bertrand Russell, Mysticism and Logic 1929

When we hear an extraordinary claim, demand extraordinary evidence.

Categories: Project Management

Operations, Finance, and Accounting for the Development of Software

Herding Cats - Glen Alleman - Fri, 03/17/2017 - 21:21

It's common to hear, projects are overhead, we just need to get the value to the customer as fast as possible. This seems to be a lament from agile developers. Anything getting in the way of them coding is seen as an impediment. 

Here's a little story.

Long ago (1978) in a land far away (Redondo Beach) I too wrote code and continued to write code for a decade or so after that. This code was for a Missile Defense system - Cobra Dane and a few satellites that supported it. My boss was a crusty engineer with a long history of delivering products to the DOD that showed up on time and on budget and worked in the defense of the nation. When us young pups arrived to move the development processes into the next century (minicomputers, high-level languages, integrated development environments) from the previous generation of punching holes in pieces of paper - either card stock or rolls of paper tape - we thought we were clearly superior to those of the past generation and were proud to tell anyone who wold listen how we had a lock on what to do best.

After tolerating our attitudes for a few months - and it was good work which is why we were hired and continued to work there for many years - Fred had a little talk. It was clear many years later, he was a good development manager and waited for the appropriate time to coach and mentor us.  In those days we got a paper paycheck and took it across the street to the Bank of America and deposited it every other Friday. The checks were handed out in envelopes by Fred personally. 

Take out your paycheck boys (very few women in those days, although my next boss - Carol - was one of the best) and look in the upper left-hand corner. It says Bank of America and the name of our company (TRW). Well, I just want to clear up a misconception here. That's not where that money comes from. The money on that check comes from the United States Airforce. The Bank of America is just holding it until you cash it. It's the United States Air Force that pays your salary and mine, and the United States Air Force wants us to do our work in the way they want, not the way you want or the way you think they want. So please consider that the next time you get some cockamamy idea that your way of doing things is better than the United States Air Force thinks you should do it. It's their money.

He liked to emphasize the full name of the customer, point out the blue suiters walking around Building O6 in Redondo Beach, not as just customers, but US Air Force customers. I work in that same domain 30 years later. Eat lunch with uniformed staff, shop at noon with stores containing uniformed personnel, stay at hotels, where uniformed personnel are eating. It's a unique environment. but one where Process is King since the money for or work comes from a sovereign.

That was a long story, so here's the point.

Screen Shot 2017-03-17 at 8.24.15 AMThe notion that process and overhead are a waste is true in some sense.

Too much process, too much overhead is a waste. But it's not your money so process and overhead are part of spending that money. And most of all, the amount of process and overhead is not likely your decision unless that decision has been assigned to you. This is how business works.

A Scrum of people works very well when doing Scrum, but operations, finance, and accounting are not the same as writing software for money. A Scrum of cost accountants, planner, finance, and operations people is called Chaos. It works for coders, not so much for others.

Projects are operational, financial, and accounting vehicles for managing and keeping track of that money. What I learned from Fred was this...

Without an understanding of where my paycheck came from, how the customer's money was turned into salaries, those salaries turned into products, and those products turned into revenue, we (all us young pups) were going to continue in our roles of being just labor. 

In those days, TRW sent a few of us back to school (MS, Systems Management, USC) to learn how to put to work the words in the book of one of the founders of our little firm, The Management of Innovative Technological Corporations, Simon Ramo, who was the R in Thompson, Ramo, and Woolrich.

There doesn't seem to be many Fred's in the world of the internet. They're still there at my clients. It's a Value at Risk thing in my opinion. 

If you hear #NoProjects, #NoManagement, #NoEstimates, #NoPlans and the people saying that are at a firm making good margin on millions of dollars of revenue good for them.

But ask how they submit the month end financial report to the investors or stockholders. You may find out they account for all that money in some form of a project - finite bounded set of work that converts cost into revenue and what's left is profit. That those numbers are assigned to discrete buckets of cost, revenue, and project and they call that a project since it's a handy way to keep all the money from getting all mixed up.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Fri, 03/17/2017 - 05:59

If you don’t pay appropriate attention to what has your attention, it will take more of your attention than it deserves. 
— David Allen, Consultant

Since all project work is uncertain, both reducible and irreducible randomness, we need to pay attention to the root causes and outcomes that impact the probability of our project's success. To make decisions on how the handle the risk created by this uncertainty, we need to estimate both the drives of this risk and the consequences of the risk. 

Screen Shot 2017-03-16 at 6.27.47 AM

Risk Management is How Adults Manage Projects - Tim Lister

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Managing in Presence of Uncertainty Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter Managing Projects By The Numbers Strategy is Not the Same as Operational Effectiveness
Categories: Project Management

Five Simple but Powerful Ways to Split User Stories

Mike Cohn's Blog - Thu, 03/16/2017 - 15:00

Today’s post introduces the second installment in a free series of training videos all about user stories. Available for a limited time only, you can watch all released videos by signing up to the Better User Stories Mini-Course. Already signed up? Check your inbox for a link to the latest video, or continue reading to find out about today’s lesson.

One of the most common struggles faced by agile teams is the need to split user stories. I'm sure you've struggled with this. I certainly did at first.

In fact, when I first began using Scrum, some of our product backlog items were so big that we occasionally opted for six-week sprints. With a bit more experience, though, that team and I saw enough ways to split work that we could have done one-day sprints if we'd wanted.

But splitting stories was hard at first. Really hard.

But I've got some good news for you. Not only have I figured out how to split stories on my own, I've learned how to explain how to do it so that anyone can quickly become an expert.

What I discovered is that almost every story can be split with one of five techniques. Learn those five simple techniques and you're set.

Even better, the five techniques form an easily memorable acronym: SPIDR.

I've just released a new, 20-minute, free video training that describes each of these techniques as part of the Better User Stories Mini-Course. To watch it simply sign up here and you’ll get instant access.

Remember, if you’ve already signed up to the course you don’t need to sign in again, just check your inbox for an email from me with a link to the latest lesson.

Unless you've already cracked the code on splitting stories, you definitely want to learn the five techniques that make up the SPIDR approach by watching this free video training.

Mike

P.S. This video is only going to be available for a very short period. I encourage you to watch it now at https://www.betteruserstories.com.

Quote of the Day

Herding Cats - Glen Alleman - Thu, 03/16/2017 - 13:52

Ignorance more frequently begets confidence than does knowledge: it is those who know little, and not those who know much, who so positively assert that this or that problem will never be solved by science. - Charles Darwin, Introduction, The Descent of Man (1871)

Categories: Project Management

Available Soon: Co-ownership of Management 3.0

NOOP.NL - Jurgen Appelo - Thu, 03/16/2017 - 13:20

Exactly one year ago, Management 3.0 was named as the front-runner of “The Third Wave of Agile“.

In 2015, the Management 3.0 workshop licensing business grew by 43%.
In 2016, our team was able to grow the annual revenue by another 45%.

What will happen in 2017?

I’m not sure. But whatever it is, you can own and enjoy the results!

Some people have accused me of being a dictator. Indeed, in the last five years, I have always been the single owner of the Management 3.0 business. But I tried to be a benevolent dictator.

Categories: Project Management

Case Studies versus Ancedotes

Herding Cats - Glen Alleman - Wed, 03/15/2017 - 21:15

It's common in the software development domain, especially agile to provide anecdotes in support for some suggested change to worked good for the person conveying the anecdote. But has not verification that the suggestion works anywhere else  

Here's some background on how to conduct a case study to support those suggestions.

Screen Shot 2017-03-15 at 2.09.20 PM

Related articles The Microeconomics of Decision Making in the Presence of Uncertainty Why We Need Governance Herding Cats: Software Development for the 21st Century Two Books in the Spectrum of Software Development
Categories: Project Management

Misunderstanding Making Decisions in the Presence of Uncertainty (Update Part 2)

Herding Cats - Glen Alleman - Tue, 03/14/2017 - 17:12

There was a Tweet a few days ago from one of the founders of eXtreme Programming, that said...

What happens if you shift focus from "accurate estimation" to "reliably shipping by a date"? 

This quote shows the missing concept of the processes for making decisions in the presence of uncertainty and the processes and events that create uncertainty that impact the reliability of making the date to ship value.

The answer is ... You can't shift focus from accurate estimate to reliably shipping by a date ...

Accurate and precise estimates (to predefined values as shown in the target picture below) are needed before you can reliably ship products by a date. Because you can't know that date with any needed level of confidence without making estimates about the reducible and irreducible uncertanties that inpact that date.

So the answer to the question is.

In the presence of uncertanity, You can't reliably ship by a date without estimating the impact of those uncertanties on the probability of making the date.

Since uncertainty creates risk, managing in the presence of uncertainty requires Risk Management, we can now answer the question, with:

  • If you want a reliable shipping date, you have to discover and handle the uncertainties in the work needed to produce the outcomes to be delivered on that date.
  • You have to estimate the needed schedule, cost, and technical performance margins needed to protect that date from the Aleatory uncertainties.
  • You have to estimate the probabilistic occurrence of the epistemic uncertainties that will impact that date and provide a Plan B an intervention, or some corrective action to protect that date.

Each of these uncertainties creates risk to meeting that reliable shipping date. And as we all know

Risk Management is How Adults Manage Projects - Tim Lister

Details of the Answer to the Question

First, let's establish a principle. All project work has uncertainty. Uncertainty comes from the lack of precision and accuracy about the possible values of a measurement of a project attribute.

There is naturally occurring variability from uncontrolled processes. There is a probability of the occurrence of a future event. This absence of knowledge (Epistemic uncertainty)  can be modeled as a probability of occurrence or a statistical distribution of the natural variability. If your project has no uncertainty, there is no need to estimate. All outcomes are certain, occurring with 100% probability, and with 0% variance. Turns out in the 

These uncertainties come in two forms. Naturally occurring variances (Aleatory uncertainty) and Event based probabilities (Epistemic uncertainty).

The naturally occurring variability comes from uncontrolled and uncontrollable processes. This uncertainty is modeled as a statistical distribution from past performance or an underlying statistical process model, usually stochastic (stationary or non-stationary). The probability of a random event is the absence of knowledge. This uncertainty is modeled as a probability of occurrence or a statistical distribution of the natural variability. If your project has no uncertainty, there is no need to estimate. All outcomes are uncertain, occurring with 100% probability, and with 0% variance.

A formal definition of uncertainty in the project decision-making paradigm is ...

Situation where the current state of knowledge is such that (1) the order or nature of things is unknown, (2) the consequences, extent, or magnitude of circumstances, conditions, or events is unpredictable, and (3) credible probabilities to possible outcomes cannot be assigned. 

If your project has no uncertainty, there is no need to estimate. Then the planned ship date is deterministic. All outcomes are certain, occurring with 100% probability, and with 0% variance.

Turns out in the real world there is no such project.

When we say uncertainty, we speak about a future state of the system that is not fixed or determined. Uncertainty is related to three aspects of the management of projects:

  1. The external world - the activities of the project itself.
  2. Our knowledge of this world - the planned and actual behaviors of the project.
  3. Our perception of this world - the data and information we receive about these behaviors.

Let's revisit the two flavors of uncertainty - uncertainty that can be reduced (Epistemic) and uncertainty that cannot be reduced (Aleatory)

Screen Shot 2017-03-11 at 1.06.11 PM
Aleatory uncertainties are unknowns that differ each time we assess them. They are values drawn from an underlying population of possible values. They are uncertainties that we can't do anything about. They cannot be suppressed or removed. My drive from my house to my secret parking spot on the east side of Denver International Airport is shown at 47 minutes by Google Maps. If I ask Google what's the duration at a specific time of day, 3 days from now, I'll get a different number. When I get on the farm road to I-25 and get to I-25 I may find a different time. This time is the random variances of distance and traffic conditions. I need margin to protect me from being late to the parking spot.

The naturally occurring work effort in the development of a software feature - even if we've built the feature before - is an irreducible uncertainty. The risk is created when we have not accounted for this natural variances in our management plan for the project. If we do not have a sufficient buffer to protect the plan from these naturally occurring variances, our project will be impacted in unfavorable ways.

The notion (as suggested in the quote) of shifting from accurate (what ever that means) ways of estimating to reliability shipping be a date is not physically possible since the irreducible and reducible uncertainties are always present.

Dealing with Aleatory (irreducible) uncertainty and the resulting risk requires we have margin. Aleatory uncertainty is expressed as a process variability. Work effort variances, productivity variances, quality of product and resulting rework variances.  Epistemic uncertainties are systematic, caused by things we know about in principle. The probability of something happening. An aleatory risk is expressed as a relation to a value. A percentage of that value. This is the motivation for short work intervals found in agile development. 

Epistemic uncertainties are systematic, caused by things we know about in principle. The probability of something happening. This uncertainty is introduced by a probabilistic event, rather than a naturally occurring process. Epistemic uncertainty is introduced by an assumption about the world in which the system is embedded. This assumption can be from the lack of data - an ontological uncertainty. Epistemic uncertainties have probabilities of occurrence. The likelihood of a failure for example. Epistemic uncertainty can also occur when there is a subjective evaluation of the system - a risk from a rare event or an event with little or no empirical data. Epistemic uncertainty can also occur from the incompleteness of knowledge - a major hazard or condition not identified or a causal mechanism the remains undetected. And epistemic uncertainty can also occur from undetected design errors, introduced by ontological uncertainties into the system behavior. 

Epistemic uncertainty can also occur when there is a subjective evaluation of the system - a risk from a rare event or an event with little or no empirical data. Epistemic uncertainty can also occur from the incompleteness of knowledge - a major hazard or condition not identified or a causal mechanism the remains undetected. And epistemic uncertainty can also occur from undetected design errors, introduced by ontological uncertainties into the system behavior. 

Before completing this post, let's look quickly at procession and accuracy as mention in the original quote. All estimates have precision and accuracy. Deciding how much precision and accuracy is needed for a credible estimate is critical to the success of that decision. One starting point is the value at risk. By determining the value at risk, we can determine how much precision and accuracy is needed and how much time and cost we should put into the estimating process.

Screen Shot 2017-03-11 at 12.39.08 PM

Let's go back to the original quote.

What happens if you shift focus from "accurate estimation" to "reliably shipping by a date"? 

With our knowledge of Epistemic and Aleatory uncertainty, we now know we cannot reliably ship by a date, without knowing the extent of the reducible and irreducible uncertainties, that protect that date with margin or reserve for the irreducible uncertainties and specific actions, redundancies, or interventions for the reducible uncertainties. To know how much margin or reserve for irreducible uncertainties and performance of the of the redundancies we now need to know. 

For our credible estimate, we must have a desired and measurable:

  • Precision - how small is the variance of the estimate?
  • Accuracy - how close is the estimate to the actual value?
  • Bias - what impacts on precision and accuracy come from human judgments?

So in the end, if we are to make a decision in the presence of uncertainty, we MUST make estimates to develop a reliable shipping date while producing an accurate and precise estimate of the cost, schedule, and technical performance of the product shipped on that date.

So it comes down to this, no matter how many times those claiming otherwise, so I'll shout this to make it clear to everyone...

YOU CANNOT MAKE A DECISION IN THE PRESENCE OF UNCERTAINTY (reducible or irreducible) WITHOUT MAKING ESTIMATES

A Short List of Resources for Managing in the Presence of Uncertainty

Risk Management is essential for development and production programs. Information about key project cost, performance, and schedule attributes is often uncertain or unknown until late in the program.
Risk issues that can be identified early in the program, which will potentially impact the program later, termed Known Unknowns can be alleviated with good risk management. in Effective Risk Management 2nd Edition, Edmund Conrow, AIAA, 2003

 

Papers on Risk Management

  1. “Quantifying Uncertainty in Early Lifecycle Cost Estimation (QUELCE),” Robert Ferguson, Dennis Goldenson, James McCurley, Robert Stoddard, David Zubrow, and Debra Anderson, Technical Report, CMU/SEI-2011-TR-026 ESC-TR-2011-026
  2. “The Development of Progress Plans Using a Performance–Based Expert Judgment Model to Assess Technical Performance and Risk,” Justin W. Eggstaff, Thomas A. Mazzuchi, and Shahram Sarkani, Systems Engineering, Volume 17, Issue 4, Winter 2014, Pages: 375–391
  3. “Using the Agile Methodology to Mitigate the Risks of Highly Adaptive Projects,” Dana Roberson and Mary Anne Herndon, 10th Annual CMMI Technology Conference And User Group, November 5 – 8, 2012, Denver, CO
  4. “Hybrid–Agile Software Development Anti–Patterns, Risks, and Recommendations,” Paul E. McMahon, Cross Talk: The Journal of Defense Software Engineering, July/August 2015, pp. 22–26.
  5. “Using the Agile Methodology to Mitigate the Risks of Highly Adaptive Projects,” Dana Roberson and Mary Anne Herndon, 10th Annual CMMI Technology Conference And User Group, November 5 – 8, 2012, Denver, CO.
  6. “Assessment of risks introduced to safety critical software by agile practices — A Software Engineer’s Perspective,” Janusz Górski Katarzyna Ɓukasiewicz, AGH University of Science and Technology, University in Kraków, Poland, Computer Science, Vol 13, No 4.
  7. “Ready & Fit: Understanding Agile Adoption Risk in DoD and Other Highly Regulated Settings,” Suzanne Miller and Mary Ann Lapham, 25th Annual Software Technology Conference, Salt Lake City, 8-10 April 2013.
  8. “Architecting Large Scale Agile Software Development: A Risk–Driven Approach,” Ipek Ozkaya, Michael Gagliardi, Robert L. Nord, CrossTalk: The Journal of Defense Software Engineering, May/June 2013.
  9. “Risk Management Method using Data from EVM in Software Development Projects,” Akihiro Hayashi and Nobuhiro Kataoka, International Conference on Computational Intelligence for Modelling, Control and Automation, Vienna, Austria, Dec. 10 to Dec. 12, 2008.
  10. “Analyse Changing Risk of Organizational Factors in Agile Project Management,” Shi Tong, Chen Jianbin, and Fang DeYing, The 1st International Conference on Information Science and Engineering (ICISE2009).
  11. “Modeling Negative User Stories is Risky Business,” Pankaj Kamthan and Nazlie Shahmir, 2016 IEEE 17th International Symposium on High Assurance Systems Engineering.
  12. “Project Risk Management Model Based on PRINCE2 and Scrum Frameworks,” Martin Tomanek, Jan Juricek, The International Journal of Software Engineering & Applications (IJSEA), January 2015, Volume 6, Number 1, ISSN: 0975-9018
  13. “How to identify risky IT projects and avoid them turning into black swans,” Magne Jþrgensen, Ernst & Young: Nordic Advisory Learning Weekend, Riga, 2016.
  14. “A Methodology for Exposing Software Development Risk in Emergent System Properties,” Technical Report 11-101, April 21, 2001, Victor Basili, Lucas Layman, and Marvin Zelkowitz, Fraunhofer Center for Experimental Software Engineering, College Park, Maryland.
  15. “Outlining a Model Integrating Risk Management and Agile Software Development,” Jaana Nyfjord and Mira Kajko-Mattsson, 34th Euromicro Conference Software Engineering and Advanced Applications.
  16. “Towards a Contingency Theory of Enterprise Risk Management,” Anette Mikes Robert Kaplan, Working Paper 13–063 January 13, 2014, AAA 2014 Management Accounting Section (MAS) Meeting Paper
  17. “Agile Development and Software Architecture: Understanding Scale and Risk,” Robert L. Nord, IEEE Software Technology Conference, 2012, Salt Lake City, 23-26 April, 2012.
  18. “Using Risk to Balance Agile and Plan Driven Methods,” Barry Boehm and Richard Turner, IEEE Computer, June 2003.
  19. “Does Risk Management Contribute to IT Project Success? A Meta-Analysis of Empirical Evidence,” Karel de Bakker, Albert Boonstra, Hans Wortmann, International Journal of Project Management, 2010.
  20. “A Model for Risk Management in Agile Software Development,” Ville Ylimannela, Communications of Cloud Software.
  21. “Product Security Risk Management in Agile Product Management,” Antti VĂ€hĂ€-SipilĂ€, OWASP AppSec Research, 2010
  22. “A Probabilistic Software Risk Assessment and Estimation Model for Software Projects,” Chandan Kumar and Dilip Kumar Yadav, Eleventh International Multi-Conference on Information Processing-2015 (IMCIP-2015)
  23. “Risk: The Final Agile Frontier,” Troy Magennis, Agile 2015.
  24. ”Risk Management and Reliable Forecasting using Un-Reliable Date,” Troy Magennis, Lean Kanban, Central Europe, 2014.
  25. “Management of risks, uncertainties and opportunities on projects: time for a fundamental shift,” Ali Jaafari, International Journal of Project Management 19 (2001) 89-101.
  26. “On Uncertainty, Ambiguity, and Complexity in Project Management,” Michael T. Pich, Christoph H. Loch, and Arnoud De Meyer, Management Science © 2002 INFORMS, Vol. 48, No. 8, August 2002 pp. 1008–1023
  27. “Risk Options and Cost of Delay,” Troy Magennis, LKNA 2014.
  28. “Transforming project risk management into project uncertainty management,” Stephen Ward and Chris Chapman, International Journal of Project Management 21 (2003) 97–105.
  29. “Risk-informed decision-making in the presence of epistemic uncertainty,” Didier Dubois, Dominique Guyonnet, International Journal of General Systems, Taylor & Francis, 2011, 40 (2), pp. 145-167.
  30. “A case study of risk management in agile systems development,” Sharon Coyle and Kieran Conboy, 17th European Conference on Information Systems (Newell S, Whitley EA, Pouloudi N, Wareham J, Mathiassen L eds.), 2567-2578, Verona, Italy, 2009
  31. “Risk management in agile methods: a study of DSDM in practice,” Sharon Coyle, 10th International Conference on eXtreme Programming and Agile Processes in Software Engineering, 2009.
  32. “Distinguishing Two Dimensions Of Uncertainty,” Craig R. Fox and GĂŒlden ÜlkĂŒmen, in Perspectives on Thinking, Judging, and Decision Making, Brun, W., Keren, G., Kirkeboen, G., & Montgomery, H. (Eds.), 2011.
  33. “Two Dimensions of Subjective Uncertainty: Clues from Natural Language,” Craig R. Fox and GĂŒlden ÜlkĂŒmen.
  34. “An Essay Towards Solving a Problem in the Doctrine of Chance,” By the late Rev. Mr. Bayes, communicated by Mr. Price, in a letter to John Canton, M. A. and F. R. S.
  35. “Playbook: Enterprise Risk Management for the U.S. Federal Government, in support of OMB Circular A-123.”
  36. “Joint Agency Cost Schedule Risk and Uncertainty Handbook,” Naval Center for Cost Analysis, 12 March 2014.
  37. “Quantitative Risk ‒ Phases 1 & 2: A013 ‒ Final Technical Report SERC-2013-TR-040-3,” Walt Bryzik and Gary Witus, November 12, 2013, Stevens Institute of Technology
  38. “Distinguishing Two Dimensions of Uncertainty,” Craig Fox and GĂŒlden Ülkumen, in Perspectives of Thinking, Judging, and Decision Making
  39. “Using Risk to Balance Agile and Plan Driven Methods,” Barry Boehm and Richard Turner, IEEE Computer, June 2003
  40. “Commonalities in Risk Management and Agile Process Models,” Jaana Nyfjord and Mira Kajko-Mattsson, International Conference on Software Engineering Advances(ICSEA 2007).
  41. “Software Risk Management in Practice: Shed Light on Your Software Product,” Jens Knodel, Matthias Naab, Eric Bouwers, Joost Visser, IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER), 2015
  42. “Software risk management,” Sergey M. Avdoshin and Elena Y. Pesotskaya, 7th Central and Eastern European Software Engineering Conference, 2011.
  43. “A New Perspective on GDSD Risk Management Agile Risk Management,” Venkateshwara Mudumba and One-Ki (Daniel) Lee, International Conference on Global Software Engineering, 2010
  44. “Using Risk Management to Balance Agile Methods: A Study of the Scrum Process,” Benjamin Gold and Clive Vassell, 2nd International Conference of Knowledge-Based Engineering and Innovation, November 5-6, 2015
  45. “Using Velocity, Acceleration, and Jerk to Manage Agile Schedule Risk,” Karen M. Bumbary, 2016 International Conference on Information Systems Engineering
  46. “The Risks of Agile Software Development Learning from Adopters,” Amany Elbanna and Suprateek Sarker, IEEE Software, September/October 2016
  47. “Software Delivery Risk Management: Application of Bayesian Networks in Agile Software Development,” Ieva Ancveire, Ilze Gailite, Made Gailite, and Janis Grabis, Information Technology and Management Science, 2015/18.
  48. “Lightweight Risk Management in Agile Projects,” Edzreena Edza Odzaly, Des Greer, Darryl Stewart, 26th Software Engineering Knowledge Engineering Conference (SEKE), November 2015.
  49. “A Method of Software Requirements Analysis Considering the Requirements Volatility from the Risk Management Point of View,” Yunarso Anang, Masakazu Takahashi, and Yoshimichi Watanabe, 22nd International Symposium on QFD, Boise, Idaho.
  50. “Analyse Changing Risk of Organizational Factors in Agile Project Management,” Shi Tong, Chen Jiabin, and Fang DeYing, The 1st International Conference on Information Science and Engineering (ICISE2009)
  51. “Outlining a Model Integrating Risk Management and Agile Software Development,” Jaana Nyfjord and Mira Kajko-Mattsson, 34th Euromicro Conference Software Engineering and Advanced Applications. 2009.
  52. “How Do Real Options Concepts Fit in Agile Requirements Engineering?,” Zornitza Racheva and Maya Daneva, Eighth ACIS International Conference on Software Engineering Research, Management and Applications, 2010..
  53. NASA Risk Informed Decision Making Handbook, NASA/SP-2010-576, Version 1.0 April, 2010.
  54. “Managing Risk Within A Decision Analysis Framework,” Homayoon Dezfuli, Robert Youngblood, Joshua Reinert, NASA Risk Management Page.
  55. “NASA Risk Management Handbook,” NASA/SP-2011-3422, Version 1.0, November 2011.
  56. “Risk Management For Software Projects In An Agile Environment – Adopting Key Lessons From The Automotive Industry,” Oana Iamandi, Marius Dan, and Sorin Popescu, Conference: MakeLearn and TIIM Joint International Conference 2015: Managing Intellectual Capital and Innovation for Sustainable and Inclusive Society, Bari, Italy, 2015
  57. “Role of Agile Methodology in Software Development,” Sonia Thakur and Amandeep Kaur, International Journal of Computer Science and Mobile Computing, Volume 2, Issue 10, October 2013, pp. 86-90
  58. “Agile Risk Management Workshop,” Alan Moran Agile Business Conference, 08.10.2014, London England
  59. “Embrace Risk! An Agile approach to risk management,” Institute for Agile Risk Management, 2014.
  60. “Risks in distributed agile development: A review,” Suprika Vasudeva Shrivastava and Urvashi Rathod, Procedia - Social and Behavioral Sciences 133 ( 2014 ) 417 – 424, ICTMS-2013
  61. “Risk and uncertainty in project management decision-making,” Karolina Koleczko, Public Infrastructure Bulletin, Vol. 1, Issue. 8 [2012], Art. 13.
  62. “Uncertainty and Project Management: Beyond the Critical Path Mentality,” A. De Meyer, C. Loch, And M. Pich, INSEAD Working Paper, 2001.
  63. “Proposal of Risk Management Metrics for Multiple Project Software Development,” Miguel Wanderleya, JĂșlio Menezes Jr., Cristine GusmĂŁoa, Filipe Limaa, Conference on ENTERprise Information Systems / International Conference on Project Management / Conference on Health and Social Care Information Systems and Technologies, CENTERIS / ProjMAN / HCist 2015 October 7-9, 2015.
  64. “Outling a Model Integration Risk Management and Agile Software Development,” Jaana Nyfjord and Mira Kajko-Mattsson, 34th Euromicro Conference Software Engineering and Advanced Applications, 2008.
  65. “The Impact Of Risk Checklists On Project Manager’s Risk Perception And Decision-Making Process,” Lei Li, Proceedings of the Southern Association for Information Systems Conference, Savannah, GA, USA March 8th–9th, 2013.
  66. “Identifying The Risks Associated With Agile Software Development: An Empirical Investigation.” Amany Elbanna, MCIS 2014 Proceedings. Paper 19.
  67. “Uncertainty, Risk, and Information Value in Software Requirements and Architecture,” Emmanuel Letier, David Stefan, and Earl T. Barr, ICSE ’14, May 31 – June 7, 2014, Hyderabad, India
  68. “Software project risk analysis using Bayesian networks with causality constraints,” Yong Hu, Xiangzhou Zhang, E. W. T. Ngai, Ruichu Cai, and Mei Liu, Decision Support Systems 56 (2013) 439–449.
  69. “Risk Based Scrum Method: A Conceptual Framework,” Nitin Uikey and Ugrasen Suman, 2015 2nd International Conference on “Computing for Sustainable Global Development, 11th - 13th March, 2015.
  70. “Implementation of Risk Management with SCRUM to Achieve CMMI Requirements,” Eman Talal Alharbi, M. Rizwan Jameel Qureshi, International Journal Computer Network and Information Security, 2014, 11, 20-25.
  71. “Risk, ambiguity, and the Savage axioms,” Daniel Ellsberg, The Quarterly Journal of Economic, Vol. 75, No. 4, pp. 643-669, Nov 1961.
  72. “Analytical Method for Probabilistic Cost and Schedule Risk Analysis: Final Report,” Prepared for NASA, 5 April 2013.
  73. “Risk, Ambiguity, and the Savage Axioms,” Daniel Ellsberg, August 1961, RAND Corporation, Report P-2173.
  74. “Dealing with Uncertainty Arising Out of Probabilistic Risk Assessment,: Kenneth Solomon, William Kastenberg, and Pamela Nelson, RAND Corporation, R-3045-ORNL, September 1983.
  75. “Using Risk to Balance Agile and Plan-Driven Methods,” Barry Boehm and Richard Turner, IEEE Computer, June 2003.
  76. “Epistemic Uncertainty Analysis: An Approach Using Expert Judgment and Evidential Credibility,” Patrick Hester, International Journal of Quality, Statistics, and Reliability, Volume 2012, Article ID 617481, 8 pages
  77. “Representation of Analysis Results Involving Aleatory and Epistemic Uncertainty,” J. C. Helton, J. D. Johnson, W. L. Oberkampf, C. J. Sallaberry, Sandia Report SAND2008-4379, 2008.
Books on Risk Management
  1. Probabilistic Risk Assessment and Management for Engineers and Scientist 2nd Edition, Ernest J. Henley and Hiromitsu Kumamoto, IEEE Press, 2000.
  2. Agile Risk Management and Scrum, Alan Moran, Institute for Agile Risk Management, 2014.
  3. Managing the Unknown: A New Approach to Managing High Uncertainty and Risk in Projects 1st Edition, Christoph H. Loch, Arnoud DeMeyer, and Michael Pich, Wiley, 2006.
  4. Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project, Tom Kendrick, AMACOM, 3rd Edition, March 2015
  5. Integrated Cost and Schedule Control in Project Management, Second Edition 2nd Edition, Ursula Kuehn, Management Concepts, 2010.
  6. Effective Risk Management, 2nd Edition, Edmund Conrow, AIAA, 2003.
  7. Effective Opportunity Management for Project: Exploiting Positive Risk, David Hillson, Taylor & Francis, 2004.
  8. Project Risk Management: Process, Techniques, and Insights, 2nd Edition, Chris Chapman and Stephen Ward, John Wiley & Sons, 2003.
  9. Managing Project Risk and Uncertainty: A Constructively Simple Approach to Decision Making, Chris Chapman and Stephen Ward, John Wiley & Sons, 2002
  10. Technical Risk Management, Jack Michaels, Prentice Hall, 1996.
  11. Managing Risk: Methods for Software Systems Development, Elaine Hall, Software Engineering Institute, Addison Wesley, 1998.
  12. Software Engineering Risk Management: Finding your Path Through the Jungle, Version 1.0, Dale Karolak, IEEE Computer Society, 1998.
  13. Risk Happens: Managing Risk and Avoiding Failure in Business Projects, Mike Clayton, Marshall Cavendish, 2011.
  14. Waltzing with Bears: Managing Risk on Software Projects, Tom Demarco and Timothy Lister, Dorset House, 2003.
  15. Software Engineering Risk Management, Dale Karolak, IEEE Computer Society Press, 1996.
  16. Practical Project Risk Management: The ATOM Methodology, David Hillson, Management Concepts Press, 2012.
  17. Risk Management in Software Development Projects, John McManus, Routledge, 2003.
  18. Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, June 2015, Office of the Deputy Assistant Secretary of Defense for Systems Engineering Washington, D.C.
  19. Project Risk Management: Process, techniques, and Insights, 2nd Edition, Chris Chapman and Stephan Ward, John Wiley & Sons, 2003.
  20. Technical Risk Management, Jack Michaels, Prentice Hall, 1996.
  21. Software Engineering Risk Management, Dale Walter Karolak, IEEE Computer Society, 1996.
  22. Software Engineering Risk Management: Finding Your Path Through the Jungle, Version 1.0, Dale Walter Karolak, IEEE Computer Society, 1998.
  23. Managing Risk: Methods for Software Systems Development, Elaine Hall, Addison Wesley, 1998.
  24. Risk Happens!: Managing Risk and Avoiding Failure in Business Projects, Mike Clayton, 2011.
  25. Probability Methods for Cost Uncertainty Analysis: A Systems Engineering Perspective, Paul Garvey, CRC Press, 2000.
  26. A Beginners Guide to Uncertainty of Measurement, Stephanie Bell, National Physics Laboratory, 1999.
  27. Practical Risk Assessment for Project Management, Stephen Grey,
  28. Assessment and Control of Software Risks, Capers Jones, Prentice Hall, 1993.
  29. Distinguishing Two Dimensions of Uncertainty, Craig Fox and GĂŒlden Ülkumen, in Perspectives of Thinking, Judging, and Decision Making

 

 

Related articles Making Decisions In The Presence of Uncertainty The Flaw of Empirical Data Used to Make Decisions About the Future Managing in Presence of Uncertainty Herding Cats: Decision Making On Software Development Projects Making Decisions in the Presence of Uncertainty Managing in the Presence of Uncertainty
Categories: Project Management

Time Sensitive: Free Access to The Better User Stories Mini-Course

Mike Cohn's Blog - Tue, 03/14/2017 - 15:00

Today I want to let you know about a new mini-course I created to help overcome some of the common and challenging problems with user stories.

It’s free to register and you can access the first video instantly, or watch it a little later at your convenience. Once you do sign-up I’ll also send you an email to let you know as soon as the next video is released.

Please note: This training is free but will only be available for the next 2 weeks

Guarantee your spot by signing up for the course today

About The Better User Stories ‘Mini-Course’

Last year I did a survey to discover what challenges were stopping people write successful user stories. Nearly 2,000 people got in touch to highlight the following issues:

  • Not writing stories that truly focus on the user’s needs
  • Wondering how to keep a team engaged from writing to development
  • Splitting stories quickly without compromising value
  • Not knowing when to add detail, or how much to include

Plus many, many more. I wanted to create a mini-course that would tackle some of these issues, and I wanted to offer it to you for free.

Even though there’s no fee to access the videos, the training isn’t light-touch, an introduction, or theory-filled. It’s based on practical materials I’ve used for teaching user stories to more than 20,000 people over the last fifteen years. What’s more, you’ll also have the chance to comment, ask questions and discuss the training featured in each video.

Join in the discussion by watching the first video now

Watch out for even more resources to help you with user stories

To go alongside the launch of the mini-course, over the next couple of weeks, both the blog and weekly tips email will feature lessons and advice on how to write better user stories.

And if you really want you and your team to master this topic, there will be an option to unlock more in-depth, advanced training (details about that coming soon).

Today, get instant access to video 1: Three Tips for Successful Story Mapping in a Story-Writing Workshop

The first video is available now. This 20 minute training looks at some of the common mistakes people make at the early stage of writing user stories, particularly when conducting a story-writing workshop.

In this video you’ll learn:

  • Why people struggle to find the balance between too much, and too little team engagement when writing user stories.
  • How to save a significant amount of time in future iteration planning by inviting the right people to your story-writing workshop
  • A simple, but powerful method of visualizing the relationship between stories
  • Practical ways to make sure your team focuses on the user’s needs at all times
  • Methods to help you prioritize and plan stories, fast

Click here to access the first video

Questions about the training? Already watched the first video? I’d love to hear from you in the comments below.