I'm hoping for some opinions to help solve a debate I'm having with
some Project Manager colleagues.
Here's the basic scenario: an agile based IT project has a number of
stories within an iteration. For a story to be accepted as
'completed', does this necessarily include any work that needs to
completed by the QA function?
For example: a story might cover something like 'Refund to a customer
their loyalty program credits". The development team will build GUI
screens and service tiers (and unit tests) that perform this. The QA
team will build GUI tier test scripts that validate the GUI
functionality and integration/system tests for the server level. Does
all of this have to be completed before a story is judged as complete
or is it just the development team's contribution?
There's another wrinkle on this question: what happens for critical
use cases where there are stringent non functional performance quality
criteria? Typically, where there is a TPS quality criteria the
development team would be expected to built stress tests that validate
their own work. Creating such stress test environments and tests is a
labourous and time consuming process, often exceeding the normal agile
iteration period. How would you organize such work in an agile
environment?
> I'm hoping for some opinions to help solve a debate I'm having with
> some Project Manager colleagues.
> Here's the basic scenario: an agile based IT project has a number of
> stories within an iteration. For a story to be accepted as
> 'completed', does this necessarily include any work that needs to
> completed by the QA function?
> For example: a story might cover something like 'Refund to a customer
> their loyalty program credits". The development team will build GUI
> screens and service tiers (and unit tests) that perform this. The QA
> team will build GUI tier test scripts that validate the GUI
> functionality and integration/system tests for the server level. Does
> all of this have to be completed before a story is judged as complete
> or is it just the development team's contribution?
> There's another wrinkle on this question: what happens for critical
> use cases where there are stringent non functional performance quality
> criteria? Typically, where there is a TPS quality criteria the
> development team would be expected to built stress tests that validate
> their own work. Creating such stress test environments and tests is a
> labourous and time consuming process, often exceeding the normal agile
> iteration period. How would you organize such work in an agile
> environment?
chet hendrickson wrote: > For a story to be accepted as > 'completed', does this necessarily include any work that needs to > completed by the QA function?
> Yes.
A user story is a mini waterfall. All of design, code, integrate, test, user-documentation, & deploy should happen, all mixed together in small tasks. The story should get any support it needs from the view and the database.
Without this rigor, then short time estimates on user stories are sweeping dirt under the rug, which must be dealt with someday...
davout wrote: > Here's the basic scenario: an agile based IT project has a number of > stories within an iteration. For a story to be accepted as > 'completed', does this necessarily include any work that needs to > completed by the QA function?
Ideally yes. But it is up to your teams definition of done.
> For example: a story might cover something like 'Refund to a customer > their loyalty program credits". The development team will build GUI > screens and service tiers (and unit tests) that perform this. The QA > team will build GUI tier test scripts that validate the GUI > functionality and integration/system tests for the server level. Does > all of this have to be completed before a story is judged as complete > or is it just the development team's contribution?
It kind of smells like the old "throw the work over the wall to QA" antipattern. Testers and developers should (once again, ideally, I am a fan of doing whatever works rather than what is rigidly prescribed) be working together, and ideally doing the tests first, and then implementing the feature that makes the test pass.
> There's another wrinkle on this question: what happens for critical > use cases where there are stringent non functional performance quality > criteria? Typically, where there is a TPS quality criteria the > development team would be expected to built stress tests that validate > their own work. Creating such stress test environments and tests is a > labourous and time consuming process, often exceeding the normal agile > iteration period. How would you organize such work in an agile > environment?
Why is it laborious and time consuming? Is the time it takes justified in the value it provides? I would try and optimize it somehow. However if things work better by keeping it outside the iteration then that should be an option. A more radical approach would be to develop within a lean, flow-based, WIP-limiting rather than iterative style, such as Kanban, which will at least help you identify issues in the value stream if not help manage them.
For a user story with significant non functional quality expectations,
it is fairly normal for the verification/QA work to exceed the
original development effort by a factor of 3 or 4. Hence, if the
original dev work is for 20 days, the QA element could consume 60+
days. This would blow apart fitting a story into a 30 day iteration.
In the agile world what's the best way of aligning long running
stories against shorter iterations?
Hold on, that isn't 60 days for one story is it? If so that is far too big. You need to reduce them by an order of magnitude.
Actually that still leaves us with 6 day stories, which is still too big.
What are your stories looking like? Someone may be able to suggest how to cut them down to size.
Maybe the stories are ok, but something else is taking too long.
What is it about developing a story that takes 20 days? What takes the longest, and why? What is it about the QA activities that takes 60 days?
Are you using appropriate engineering practices?
Are there any bottlenecks? Is anyone idle waiting on work? Is anyone swamped with work? Maybe some value stream mapping can tell you where things are spending all that time and you can target some improvements there.
I suspect both your stories are too big, and somewhere, things are being done the hard way rather than the smart way.
> For a user story with significant non functional quality expectations, > it is fairly normal for the verification/QA work to exceed the > original development effort by a factor of 3 or 4. Hence, if the > original dev work is for 20 days, the QA element could consume 60+ > days. This would blow apart fitting a story into a 30 day iteration. > In the agile world what's the best way of aligning long running > stories against shorter iterations?
Let's take an example: for instance an online gambling service. The
user story might be: "accept spread bets from customers after event
has started and before it has finished". The plain vanilla coding for
such a scenario might be straightforward but the non-functional
quality criteria on performance and scalability make this far more
complicated. Hence, the same user story with the relecvant quality
quakifications might read: "accept spread bets from customers after
event has started and before it has finished, completing each
transaction within 2 seconds allowing up to 500,000 concurrent
transactions".
Add to this the need to create a range of stress test environments to
validate performance and scalability criteria and you've got yourself
a large body of work. If the dev shop were an ISV selling this as a
product to online gambling services then you'd need to add in testing
across multiple O/S and hardware combinations.
|
