5 added 261 characters in body
source | link

There are two parts to this: QA and Planning.

QA

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.


Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.


You already have quality standards that you deem important. You listed them in the question.

What you're not doing is assuring that all stories meet the quality standards. What you need to do is to assure that all stories meet the quality standards before you use them for estimating.

Planning

You probably have unrealistic expectations for a "a great high-level plan". If you think you're going to estimate to within a small factor of the final project cost, you're being naive. You're initial planning is not actually of any value at all.

Zero.

The Agile (specifically Scrum) folks will tell you that the backlog is a very, very flexible thing that grows and shrinks wildly as people learn about the product, the stories, the technology and the problem domain.

The initial estimate is not really useful for anything, since many of the low-priority user stories can easily be removed. Some of the user stories are really epics with numerous user stories buried within them. Some of the user stories are flat-out wrong. And some of the user stories only hint at the real problem that needs to be solved.

After a few sprints, the backlog combined with the delivered features looks very little like the initial backlog. This is the sign of a well-run project where people have permission to learn something and fix the backlog to reflect that learning.

"leads to valuable plan/results." is a backlog. Not much more than a list of stories and relative complexities. Detailed estimates based on super-accurate stories don't actually help develop software. All that detailed estimates help with is estimation.

"A great high level plan isn't just a set of functional requirements, but rather a product vision with obvious goal in mind" Is a backlog. Nothing more. Detailed estimates. High quality user stories aren't essential. Bad user stories are part of a great plan because they get reworked to improve their quality.

There are two parts to this: QA and Planning.

QA

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.


Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.


You already have quality standards that you deem important. You listed them in the question.

What you're not doing is assuring that all stories meet the quality standards. What you need to do is to assure that all stories meet the quality standards before you use them for estimating.

Planning

You probably have unrealistic expectations for a "a great high-level plan". If you think you're going to estimate to within a small factor of the final project cost, you're being naive. You're initial planning is not actually of any value at all.

Zero.

The Agile (specifically Scrum) folks will tell you that the backlog is a very, very flexible thing that grows and shrinks wildly as people learn about the product, the stories, the technology and the problem domain.

The initial estimate is not really useful for anything, since many of the low-priority user stories can easily be removed. Some of the user stories are really epics with numerous user stories buried within them. Some of the user stories are flat-out wrong. And some of the user stories only hint at the real problem that needs to be solved.

After a few sprints, the backlog combined with the delivered features looks very little like the initial backlog. This is the sign of a well-run project where people have permission to learn something and fix the backlog to reflect that learning.

There are two parts to this: QA and Planning.

QA

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.


Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.


You already have quality standards that you deem important. You listed them in the question.

What you're not doing is assuring that all stories meet the quality standards. What you need to do is to assure that all stories meet the quality standards before you use them for estimating.

Planning

You probably have unrealistic expectations for a "a great high-level plan". If you think you're going to estimate to within a small factor of the final project cost, you're being naive. You're initial planning is not actually of any value at all.

Zero.

The Agile (specifically Scrum) folks will tell you that the backlog is a very, very flexible thing that grows and shrinks wildly as people learn about the product, the stories, the technology and the problem domain.

The initial estimate is not really useful for anything, since many of the low-priority user stories can easily be removed. Some of the user stories are really epics with numerous user stories buried within them. Some of the user stories are flat-out wrong. And some of the user stories only hint at the real problem that needs to be solved.

After a few sprints, the backlog combined with the delivered features looks very little like the initial backlog. This is the sign of a well-run project where people have permission to learn something and fix the backlog to reflect that learning.

"leads to valuable plan/results." is a backlog. Not much more than a list of stories and relative complexities. Detailed estimates based on super-accurate stories don't actually help develop software. All that detailed estimates help with is estimation.

"A great high level plan isn't just a set of functional requirements, but rather a product vision with obvious goal in mind" Is a backlog. Nothing more. Detailed estimates. High quality user stories aren't essential. Bad user stories are part of a great plan because they get reworked to improve their quality.

4 added 1475 characters in body
source | link

There are two parts to this: QA and Planning.

QA

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.


Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.


You already have quality standards that you deem important. You listed them in the question.

What you're not doing is assuring that all stories meet the quality standards. What you need to do is to assure that all stories meet the quality standards before you use them for estimating.

Planning

You probably have unrealistic expectations for a "a great high-level plan". If you think you're going to estimate to within a small factor of the final project cost, you're being naive. You're initial planning is not actually of any value at all.

Zero.

The Agile (specifically Scrum) folks will tell you that the backlog is a very, very flexible thing that grows and shrinks wildly as people learn about the product, the stories, the technology and the problem domain.

The initial estimate is not really useful for anything, since many of the low-priority user stories can easily be removed. Some of the user stories are really epics with numerous user stories buried within them. Some of the user stories are flat-out wrong. And some of the user stories only hint at the real problem that needs to be solved.

After a few sprints, the backlog combined with the delivered features looks very little like the initial backlog. This is the sign of a well-run project where people have permission to learn something and fix the backlog to reflect that learning.

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.


Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.

There are two parts to this: QA and Planning.

QA

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.


Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.


You already have quality standards that you deem important. You listed them in the question.

What you're not doing is assuring that all stories meet the quality standards. What you need to do is to assure that all stories meet the quality standards before you use them for estimating.

Planning

You probably have unrealistic expectations for a "a great high-level plan". If you think you're going to estimate to within a small factor of the final project cost, you're being naive. You're initial planning is not actually of any value at all.

Zero.

The Agile (specifically Scrum) folks will tell you that the backlog is a very, very flexible thing that grows and shrinks wildly as people learn about the product, the stories, the technology and the problem domain.

The initial estimate is not really useful for anything, since many of the low-priority user stories can easily be removed. Some of the user stories are really epics with numerous user stories buried within them. Some of the user stories are flat-out wrong. And some of the user stories only hint at the real problem that needs to be solved.

After a few sprints, the backlog combined with the delivered features looks very little like the initial backlog. This is the sign of a well-run project where people have permission to learn something and fix the backlog to reflect that learning.

3 added 174 characters in body
source | link

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.


Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.


Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.

2 added 3 characters in body
source | link
1
source | link