Input on breaking down an epic

[adam_peter.knight]

We have a requirement that is currently under discussion which I thought
I'd get some input from the group on.

As a bit of background, we are testing a data archiving system
(essentially a read-only database).

A new requirement is to be able to expire individual records from the
system based on a date/retention period applied to each record
individually. The issue, which I have touched on before in this forum,
is this.

The high level requirement could be written something like:-

"As an archive administrator I want to be able to expire data from the
system at the record level so that I can expire data from the system on
a policy basis"

However this is far too large to fit into a sprint.

When we try to break it down I hit two issues:
a. The development lead still doesn't like using stories and would
rather just tackle the whole requirement and expose to test once it is
ready
b. It is hard to break down into items that can be delivered and provide
value to the user.

My initial thoughts on a breakdown would be something like:-
1. As a developer I want to be able to uniquely identify each record in
the archive through an ODBC/JDBC interface so that I may apply expiry
and deletion policies for individual records ( already in progress, I
wouldn't have come up with this as a story necessarily)
2. As an archive  administrator I want to apply a default expiry date to
all records in an import so that I can then expire those records at a
later date
3. As an archive  administrator I want tobe able to modify the expiry
date of individual records in an archive so that I can apply expiry
policies to records in my archive
4. As an archive  administrator I want to be able to uniquely identify
each record in the archive through an ODBC/JDBC interface so that I may
create expiry and deletion  record lists based on policies based on the
record content
5. As an archive  administrator I want to be able to expire records in
the archive that have passed their expiry date so that expired records
are no longer queryable in the archive

The issues that I have are

i) 1 and 4 are very similar stories, the difference being that for 1 we
are implementing the functionality for internal use and are testing it
accordingly, but we will then expose it at a later date to the user
which will require more extensive testing. This means that a large
portion of the testing on this will take place in the sprint after the
main functionality was delivered leaving us open to falling behind in
test.
ii) Under the banner of 'research' the developers are in the process of
developing support for 2 and 3, although they are not planning to
deliver this in the current sprint so we have nothing to test, again
leaving us open to testing in the sprint after development effort.
iii) I have broken down 2) and 3) to try to allow us to test earlier
against this functionality, however 2) does not deliver any significant
value to the user without 3 or 5. If I combine these as a larger story
then it is too big for a sprint and we won't see anything to test until
at least 1 sprint of development has already been done.

We have been working very well developing and testing together in recent
sprints, however when we encounter large epic stories like this I always
hit the issue that the developers want to develop the epic as a single
requirement and see the stories simply as a test mechanism, and I seem
to have to work to keep the sprint process together.

Regards,

Adam.

PS If anyone out there has worked in agile specifically on data
storage/analysis systems then I'd be interested in comparing notes.
----------------------------------------------------------
http://www.linkedin.com/in/adampknight
http://a-sisyphean-task.blogspot.com
adam.knight@...
----------------------------------------------------------

[Hubert Matthews]

It sounds like there is a lot of research that has to be done about the
best way to implement this, both at the database level and at the spec and
UI levels.  Agile projects typically aren't good at research; they focus
on fast execution.  My guess is that you want to do this as a feature
branch off the mainline with defined research iterations: what do we need
to learn, what questions do we need to ask and what tasks do we need to do
to answer them.  Once you have that knowledge and learning under your belt
then you can move into fast faultless execution.  If you try to do this
learning in the mainline then you will most likely stall the pipeline and
you'll miss your targets (or more likely testing will get badly squeezed).

Knowledge acquisition and producing code are different things.  Not
acknowledging the role of the former and trying to mix it in with the
latter results in problems when there's lots of learning to do.

--
Hubert Matthews         http://www.oxyware.com/
Software Consultant     hubert@...

[Adrian Howard]

On 9 Oct 2009, at 09:34, adam_peter.knight wrote:
[snip]
> a. The development lead still doesn't like using stories and would
> rather just tackle the whole requirement and expose to test once it is
> ready
[snip]

Any idea why? Wearing my developer hat I like developing things in  
small chunks... so I'd be interested in their reasons. Just don't  
think it's possible? Think it's wasteful? Something else?

Adrian

--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Adrian Howard]

On 9 Oct 2009, at 10:03, Hubert Matthews wrote:

> It sounds like there is a lot of research that has to be done about  
> the
> best way to implement this, both at the database level and at the  
> spec and
> UI levels.  Agile projects typically aren't good at research; they  
> focus
> on fast execution.
[snip]

That's not been my experience. As far as I'm concerned Agile projects  
concentrate on the incremental delivery of value - not speed. That  
seems to work quite well with research in my experience (when wearing  
my UX research hat :-)

I'd love to hear about your experiences of it going badly.

Cheers,

Adrian
--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Hubert Matthews]

Adrian Howard wrote:

> On 9 Oct 2009, at 10:03, Hubert Matthews wrote:
>
>> It sounds like there is a lot of research that has to be done about  
>> the
>> best way to implement this, both at the database level and at the  
>> spec and
>> UI levels.  Agile projects typically aren't good at research; they  
>> focus
>> on fast execution.
> [snip]
>
> That's not been my experience. As far as I'm concerned Agile projects  
> concentrate on the incremental delivery of value - not speed. That  
> seems to work quite well with research in my experience (when wearing  
> my UX research hat :-)
>
> I'd love to hear about your experiences of it going badly.

I've seen agile teams get bogged down by trying to write deliverable
code before they know what it is that they are trying to write.  I've
also seen them get stuck when there have been big blockers such as the
unavailability of test data from another system.

Yes, agile is good at learning in the small but for longer or larger
research then we may need to step away from the keyboard for a moment
and do non-code-oriented iterations or proof-of-concept
non-deliverable work.  Another case is when you have some major
upheaval or a large feature change where you need to take the whole
thing apart and put it back together again later.  This sort of work
rarely has stable intermediate forms and so practices like CI don't work.

Incremental delivery of value is important.  We just have to have a
clear idea that value does not always mean code.  Sometimes research,
prototypes, plans, etc are more valuable.

--
Hubert Matthews         http://www.oxyware.com/
Software Consultant     hubert@...

[Voris, John]

I don't know if this is exactly what you want to hear about breaking
down an Epic, but as was discussed previously, it *is* about the
learning experience.

Those of us with large database applications deal with
Expiry/Inactivation/Purge of individual records all the time.

As a practical matter, the easiest solution is, within the first sprint,
affix an inactivation code as a column within the database files.  Along
with this may be other columns for Expires-on-Date and sometimes a
column for Expired-due-to-Policy.

Once these are columns are in place, then the learning cycle can begin.
You can then develop-policies/learn/play with the database fields *of
the production data* independent of production processes to figure out
the policies you will build for expiring and purging.  You can now have
good dialogues with the users/customers about the new processes "We will
expire details based on X unless they are multiline orders which had
backorders which were still pending within fiscal year Y, but knowing
that product Z on an order must be retained for an additional 3 years".
And within the production database, you can now point to examples of
these what-ifs because the policies were tagged in records.  And
hierarchy of policies often develop, where one policy may overlay
another during this exercise.

This is all straight-forward, but it begins with amendment of the
database to assist with learning what new policies should be considered,
and doing that with examples from the live database (which the users are
more intimately familiar with) rather than with "perfect examples" in a
test environment.  Test environments may not get you the feedback you
really need.

And also, do not forget to include a policy of "manual override" where
the user says "nope, that should not get purged now, because I have a
gut feel about this product/division/customer-status"  That is a policy
that is dying to be defined.


> As a bit of background, we are testing a data archiving system

> A new requirement is to be able to expire individual records from the
> system based on a date/retention period applied to each record
> individually. The issue, which I have touched on before in this forum,
> is this.

[Kaleb Pederson-2]

On Friday 09 October 2009 01:34:29 am adam_peter.knight wrote:

> We have a requirement that is currently under discussion which I thought
> I'd get some input from the group on.
>
> As a bit of background, we are testing a data archiving system
> (essentially a read-only database).
>
> A new requirement is to be able to expire individual records from the
> system based on a date/retention period applied to each record
> individually. The issue, which I have touched on before in this forum,
> is this.
>
> The high level requirement could be written something like:-
>
> "As an archive administrator I want to be able to expire data from the
> system at the record level so that I can expire data from the system on
> a policy basis"
>
> However this is far too large to fit into a sprint.

That story not only seems quite big, but also seems quite ambiguous.  Using just that story, I'm not sure whether the data should be deleted from the archive or marked as expired?  I also have no idea when it should be expired, if it applies to all records, or only some of the records, or how the policies may be defined.

> When we try to break it down I hit two issues:
> a. The development lead still doesn't like using stories and would
> rather just tackle the whole requirement and expose to test once it is
> ready
> b. It is hard to break down into items that can be delivered and provide
> value to the user.

I've had that feeling before.

Maybe we can discuss and see if it can be broken down more.

1) What kinds of things show up in the expiry policies?
2) What happens to the records once it expires?
3) Do all records expire at once or do different records have various life spans?
4) Is there anything in those records or policies that can be used to segment or further break down the story?

> My initial thoughts on a breakdown would be something like:-
> 1. As a developer I want to be able to uniquely identify each record in
> the archive through an ODBC/JDBC interface so that I may apply expiry
> and deletion policies for individual records ( already in progress, I
> wouldn't have come up with this as a story necessarily)

A super-simple solution would be adding a single primary key field, but I have a feeling that there's a lot more involved in your story.  Can you clarify what it means to uniquely identify each record?  And once you can uniquely identify each record, what's happening with the "apply expiry and deletion policies".

It sounds like uniquely identifying the records might be quite important and be worthy of being considered a story in itself?

> 2. As an archive  administrator I want to apply a default expiry date to
> all records in an import so that I can then expire those records at a
> later date

Does this mean that it's important to know about batches (or imports) that were loaded into a system? If so, should it be a story unto itself?

I imagine there's other similar questions I could ask about your remaining items.  One thing that's worth considering is whether there is any subset of functionality represented by that story that could be useful to the user.  For example, if you were to add two fields (if not already present), such as import_date and record_lifespan, would it be possible for the user to exclude the records from their queries as if they had been expired?  Of course, this is the difficult part.  

If you can come up with some good vertical slices (slices of functionality that span all the aspects of the process, but is in somehow limited), you'll likely have good user stories -- a story representing functionality from which the user could benefit if implemented all by itself.

Have customer's given you any hint of such functionality? Eric Reis discusses minimum viable product (http://www.startuplessonslearned.com/2009/03/minimum-viable-product.html).  I think, ultimately, this should be the goal of every story.  If we can identify and implement the minimum viable story, with each subsequent story being the minimum viable expansion desired by users, then you'll be in good shape.

If only at were as easy done as said.

--Kaleb

http://twitter.com/kalebpederson
http://kalebpederson.com

> 3. As an archive  administrator I want tobe able to modify the expiry
> date of individual records in an archive so that I can apply expiry
> policies to records in my archive
> 4. As an archive  administrator I want to be able to uniquely identify
> each record in the archive through an ODBC/JDBC interface so that I may
> create expiry and deletion  record lists based on policies based on the
> record content
> 5. As an archive  administrator I want to be able to expire records in
> the archive that have passed their expiry date so that expired records
> are no longer queryable in the archive
>
> The issues that I have are
>
> i) 1 and 4 are very similar stories, the difference being that for 1 we
> are implementing the functionality for internal use and are testing it
> accordingly, but we will then expose it at a later date to the user
> which will require more extensive testing. This means that a large
> portion of the testing on this will take place in the sprint after the
> main functionality was delivered leaving us open to falling behind in
> test.
> ii) Under the banner of 'research' the developers are in the process of
> developing support for 2 and 3, although they are not planning to
> deliver this in the current sprint so we have nothing to test, again
> leaving us open to testing in the sprint after development effort.
> iii) I have broken down 2) and 3) to try to allow us to test earlier
> against this functionality, however 2) does not deliver any significant
> value to the user without 3 or 5. If I combine these as a larger story
> then it is too big for a sprint and we won't see anything to test until
> at least 1 sprint of development has already been done.
>
> We have been working very well developing and testing together in recent
> sprints, however when we encounter large epic stories like this I always
> hit the issue that the developers want to develop the epic as a single
> requirement and see the stories simply as a test mechanism, and I seem
> to have to work to keep the sprint process together.
>
> Regards,
>
> Adam.
>
> PS If anyone out there has worked in agile specifically on data
> storage/analysis systems then I'd be interested in comparing notes.
> ----------------------------------------------------------
> http://www.linkedin.com/in/adampknight
> http://a-sisyphean-task.blogspot.com
> adam.knight@...
> ----------------------------------------------------------
>
>
>
>
>

[adam_peter.knight]

They just don't think it is possible, or relevant to them. The
deliverable is the whole thing to them and they want to develop it as a
large requirement rather than having to worry about finding and
delivering valuable, testable sub-items as smaller stories.

Adam.
----------------------------------------------------------
http://www.linkedin.com/in/adampknight
http://a-sisyphean-task.blogspot.com
----------------------------------------------------------
--- In agile-testing@..., Adrian Howard <adrianh@...> wrote:
>
>
> On 9 Oct 2009, at 09:34, adam_peter.knight wrote:
> [snip]
> > a. The development lead still doesn't like using stories and would
> > rather just tackle the whole requirement and expose to test once it
is

> > ready
> [snip]
>
> Any idea why? Wearing my developer hat I like developing things in
> small chunks... so I'd be interested in their reasons. Just don't
> think it's possible? Think it's wasteful? Something else?
>
> Adrian
>
> --
> http://quietstars.com  -  twitter.com/adrianh  -

delicious.com/adrianh
>

[adam_peter.knight]

--- In agile-testing@..., Kaleb Pederson <kaleb.pederson@...> wrote:
> That story not only seems quite big, but also seems quite ambiguous.  Using just that story, I'm not sure whether the data should be deleted from the archive or marked as expired?  I also have no idea when it should be expired, if it applies to all records, or only some of the records, or how the policies may be defined.
The initial requirement is that records will be marked as expired and then no longer appear in query results. Later stories will deal with physical deletion.

>
> > When we try to break it down I hit two issues:
> > a. The development lead still doesn't like using stories and would
> > rather just tackle the whole requirement and expose to test once it is
> > ready
> > b. It is hard to break down into items that can be delivered and provide
> > value to the user.
>
> I've had that feeling before.
>
> Maybe we can discuss and see if it can be broken down more.
>
> 1) What kinds of things show up in the expiry policies?

These will be based on SQL Queries, we have no example queries from the customer.
> 2) What happens to the records once it expires?
Remains in the data files but ceases to appear in query results.
> 3) Do all records expire at once or do different records have various life spans?
Different records will have different life spans based on the expiry dates applied to each record.
> 4) Is there anything in those records or policies that can be used to segment or further break down the story?
We are not dealing with a specific system, ours is a backend that must support multiple data models and policies, so, not really.
>
> > My initial thoughts on a breakdown would be something like:-
> > 1. As a developer I want to be able to uniquely identify each record in
> > the archive through an ODBC/JDBC interface so that I may apply expiry
> > and deletion policies for individual records ( already in progress, I
> > wouldn't have come up with this as a story necessarily)
>
> A super-simple solution would be adding a single primary key field, but I have a feeling that there's a lot more involved in your story.  Can you clarify what it means to uniquely identify each record?  And once you can uniquely identify each record, what's happening with the "apply expiry and deletion policies".
We have no control over the data model, it is defined by the customer. If they have no primary key in their data then we will require a mechanism to identify records in the data (without modifying the data itself - we are an archive) to allow expiry dates to be changed.
>
> It sounds like uniquely identifying the records might be quite important and be worthy of being considered a story in itself?
Yes that is the basis of Story (1)
>
> > 2. As an archive  administrator I want to apply a default expiry date to
> > all records in an import so that I can then expire those records at a
> > later date
>
> Does this mean that it's important to know about batches (or imports) that were loaded into a system? If so, should it be a story unto itself?
We already do know about batches, it is a by product of the structure of our system.
>
> I imagine there's other similar questions I could ask about your remaining items.  One thing that's worth considering is whether there is any subset of functionality represented by that story that could be useful to the user.  For example, if you were to add two fields (if not already present), such as import_date and record_lifespan, would it be possible for the user to exclude the records from their queries as if they had been expired?  Of course, this is the difficult part.  
That is where I am struggling, there are very few deliverables here that would be useful to the customer without all of the others.
>
> If you can come up with some good vertical slices (slices of functionality that span all the aspects of the process, but is in somehow limited), you'll likely have good user stories -- a story representing functionality from which the user could benefit if implemented all by itself.
>
> Have customer's given you any hint of such functionality? Eric Reis discusses minimum viable product (http://www.startuplessonslearned.com/2009/03/minimum-viable-product.html).  I think, ultimately, this should be the goal of every story.  If we can identify and implement the minimum viable story, with each subsequent story being the minimum viable expansion desired by users, then you'll be in good shape.
>
> If only at were as easy done as said.
You are right there.

>
> --Kaleb
>
> http://twitter.com/kalebpederson
> http://kalebpederson.com
>
>
> > 3. As an archive  administrator I want tobe able to modify the expiry
> > date of individual records in an archive so that I can apply expiry
> > policies to records in my archive
> > 4. As an archive  administrator I want to be able to uniquely identify
> > each record in the archive through an ODBC/JDBC interface so that I may
> > create expiry and deletion  record lists based on policies based on the
> > record content
> > 5. As an archive  administrator I want to be able to expire records in
> > the archive that have passed their expiry date so that expired records
> > are no longer queryable in the archive
> >
> > The issues that I have are
> >
> > i) 1 and 4 are very similar stories, the difference being that for 1 we
> > are implementing the functionality for internal use and are testing it
> > accordingly, but we will then expose it at a later date to the user
> > which will require more extensive testing. This means that a large
> > portion of the testing on this will take place in the sprint after the
> > main functionality was delivered leaving us open to falling behind in
> > test.
> > ii) Under the banner of 'research' the developers are in the process of
> > developing support for 2 and 3, although they are not planning to
> > deliver this in the current sprint so we have nothing to test, again
> > leaving us open to testing in the sprint after development effort.
> > iii) I have broken down 2) and 3) to try to allow us to test earlier
> > against this functionality, however 2) does not deliver any significant
> > value to the user without 3 or 5. If I combine these as a larger story
> > then it is too big for a sprint and we won't see anything to test until
> > at least 1 sprint of development has already been done.
> >
> > We have been working very well developing and testing together in recent
> > sprints, however when we encounter large epic stories like this I always
> > hit the issue that the developers want to develop the epic as a single
> > requirement and see the stories simply as a test mechanism, and I seem
> > to have to work to keep the sprint process together.
> >
> > Regards,
> >
> > Adam.
> >
> > PS If anyone out there has worked in agile specifically on data
> > storage/analysis systems then I'd be interested in comparing notes.
> > ----------------------------------------------------------
> > http://www.linkedin.com/in/adampknight
> > http://a-sisyphean-task.blogspot.com
> > adam.knight@...
> > ----------------------------------------------------------
> >
> >
> >
> >
> >
>

[Steven Gordon-2]

What has the customer's experience been with big bang, ambiguous,
all-or-nothing requirements?  Has the customer been happy with the results?
How often do they say what they got was not what they asked for?  How often
do they say they got what they asked for but it does not really work well
for them?  How often do they ask for changes in what they got?

If the customer is almost always happy with what they get and the rework is
minimal, it is hard to make a case for slicing.  If not, it is very easy to
make the case.

Like somebody else suggested, a story which implements the 'null policy' and
allow the user to manually schedule the expiration of individual records is
a good place to start.  Then they can at least use that, see what policies
they would like to have in practice, and they will have the ability to
manually override whatever policies do get added.  After that, each
additional slice is a the implementation of a single new policy.

On Fri, Oct 9, 2009 at 9:06 AM, adam_peter.knight <adam.knight@...
> wrote:

>
>
> They just don't think it is possible, or relevant to them. The deliverable
> is the whole thing to them and they want to develop it as a large
> requirement rather than having to worry about finding and delivering
> valuable, testable sub-items as smaller stories.
>
> Adam.
>
> ----------------------------------------------------------
> http://www.linkedin.com/in/adampknight
> http://a-sisyphean-task.blogspot.com
> ----------------------------------------------------------
>
>
> --- In agile-testing@..., Adrian Howard <adrianh@...> wrote:
> >
> >
> > On 9 Oct 2009, at 09:34, adam_peter.knight wrote:
> > [snip]
> > > a. The development lead still doesn't like using stories and would
> > > rather just tackle the whole requirement and expose to test once it is
> > > ready
> > [snip]
> >
> > Any idea why? Wearing my developer hat I like developing things in
> > small chunks... so I'd be interested in their reasons. Just don't
> > think it's possible? Think it's wasteful? Something else?
> >
> > Adrian
> >
> > --
> > http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
> >
>
>  
>

[adam_peter.knight]

Thanks for the response..
--- In agile-testing@..., Steven Gordon <sgordonphd@...>
wrote:
>
> What has the customer's experience been with big bang, ambiguous,
> all-or-nothing requirements?  Has the customer been happy with the
results?
> How often do they say what they got was not what they asked for?  How
often
> do they say they got what they asked for but it does not really work
well
> for them?  How often do they ask for changes in what they got?
Our customers prefer infrequent releases with large scale product
improvements due to the overheads that they have in validating and
rolling out each new version (our customers integrate our product into
their own, and each has multiple installations of their own product so
upgrading is an expensive process)> If the customer is almost always
happy with what they get and the rework is
> minimal, it is hard to make a case for slicing.  If not, it is very
easy to
> make the case.
As you say it is hard to make the case other than to ensure that the
test and development efforts continue to work in parallel and we
maintain continuous integration.
>
> Like somebody else suggested, a story which implements the 'null
policy' and
> allow the user to manually schedule the expiration of individual
records is
> a good place to start.  Then they can at least use that, see what
policies
> they would like to have in practice, and they will have the ability to
> manually override whatever policies do get added.  After that, each
> additional slice is a the implementation of a single new policy.
We're not really adding policies ourselves, just the mechanism in our
system to apply the policies, so in essence even if we deliver 'null
policy' we have completed the requirement, designing the policies
themselves is up to the customer. I was thinking of having the ability
to set expiry dates at import time as one story and then the ability to
change the dates for individial records via SQL policies as another ,
these are still pretty sizeable stories though and it could still be
argued that neither is much use without the third story of actually
being able to expire the records based on the dates applied.
>
> On Fri, Oct 9, 2009 at 9:06 AM, adam_peter.knight adam.knight@...
> > wrote:
>
> >
> >
> > They just don't think it is possible, or relevant to them. The
deliverable

> > is the whole thing to them and they want to develop it as a large
> > requirement rather than having to worry about finding and delivering
> > valuable, testable sub-items as smaller stories.
> >
> > Adam.
> >
> > ----------------------------------------------------------
> > http://www.linkedin.com/in/adampknight
> > http://a-sisyphean-task.blogspot.com
> > ----------------------------------------------------------
> >
> >
> > --- In agile-testing@..., Adrian Howard adrianh@ wrote:
> > >
> > >
> > > On 9 Oct 2009, at 09:34, adam_peter.knight wrote:
> > > [snip]
> > > > a. The development lead still doesn't like using stories and

would
> > > > rather just tackle the whole requirement and expose to test once
it is

> > > > ready
> > > [snip]
> > >
> > > Any idea why? Wearing my developer hat I like developing things in
> > > small chunks... so I'd be interested in their reasons. Just don't
> > > think it's possible? Think it's wasteful? Something else?
> > >
> > > Adrian
> > >
> > > --
> > > http://quietstars.com - twitter.com/adrianh -

delicious.com/adrianh
> > >
> >
> >
> >
>

[adam_peter.knight]

Thanks John, some comments below.
--- In agile-testing@..., "Voris, John" <john.voris@...>
wrote:
>
> I don't know if this is exactly what you want to hear about breaking
> down an Epic, but as was discussed previously, it *is* about the
> learning experience.
>
> Those of us with large database applications deal with
> Expiry/Inactivation/Purge of individual records all the time.
>
> As a practical matter, the easiest solution is, within the first
sprint,
> affix an inactivation code as a column within the database files.
Along
> with this may be other columns for Expires-on-Date and sometimes a
> column for Expired-due-to-Policy.
Sadly we don't have control over the database schema, we simply provide
the software to store the data, the customer designs the schema based on
the data that they want to store, much as they would with a database or
data warehouse, our requirement is to implement the ability to expire
records that the customer imports into the system.
> Once these are columns are in place, then the learning cycle can
begin.
> You can then develop-policies/learn/play with the database fields *of
> the production data* independent of production processes to figure out
> the policies you will build for expiring and purging.  You can now
have
> good dialogues with the users/customers about the new processes "We
will
> expire details based on X unless they are multiline orders which had
> backorders which were still pending within fiscal year Y, but knowing
> that product Z on an order must be retained for an additional 3
years".
> And within the production database, you can now point to examples of
> these what-ifs because the policies were tagged in records.  And
> hierarchy of policies often develop, where one policy may overlay
> another during this exercise.

It will be our customers who design and apply the expiry policies, we
just need to provide a mechanism within the storage system for them to
do this, this is good in one way that we don't have to design and test
the policies, but makes life more difficult in that we need to cater for
any policy that the customer may decide to apply.
>
> This is all straight-forward, but it begins with amendment of the
> database to assist with learning what new policies should be
considered,
> and doing that with examples from the live database (which the users
are
> more intimately familiar with) rather than with "perfect examples" in
a
> test environment.  Test environments may not get you the feedback you
> really need.

We have a series of test data structures that try to replicate examples
of the types of data structure we see in live use which we can use to
test this, we don't have exposure to live systems are we are one step
removed from the actual implementations. I think we may need to obtain
more specific policy information from the customers to allow us to focus
our testing, however.
>
> And also, do not forget to include a policy of "manual override" where
> the user says "nope, that should not get purged now, because I have a
> gut feel about this product/division/customer-status"  That is a
policy
> that is dying to be defined.
>
>
> > As a bit of background, we are testing a data archiving system
>
> > A new requirement is to be able to expire individual records from
the
> > system based on a date/retention period applied to each record
> > individually. The issue, which I have touched on before in this
forum,
> > is this.
>

[Kaleb Pederson-2]

Adam,

Thanks for the detailed responses to my earlier message.  I have one
comment  which is inline below and directly related to Steven Gordon's
question:

On Fri, Oct 9, 2009 at 10:05 AM, adam_peter.knight <
adam.knight@...> wrote:

>
>
> Thanks for the response..
>
> --- In agile-testing@..., Steven Gordon <sgordonphd@...>
> wrote:
> >
> > What has the customer's experience been with big bang, ambiguous,
> > all-or-nothing requirements? Has the customer been happy with the
> results?
> > How often do they say what they got was not what they asked for? How
> often
> > do they say they got what they asked for but it does not really work well
> > for them? How often do they ask for changes in what they got?
>
> Our customers prefer infrequent releases with large scale product
> improvements due to the overheads that they have in validating and rolling
> out each new version (our customers integrate our product into their own,
> and each has multiple installations of their own product so upgrading is an
> expensive process)
>

I thought Steve was asking a different question, one that you didn't answer.

Isn't the real question about the requirements rather than the
implementation?  Having worked in an enterprise environment for a number of
years, I didn't want to deal with frequent system implementations, but I
desperately wished I could be more involved in requirement definitions.
Whenever one of the newly implemented requirements didn't do what we needed,
it was my job to make modifications to the system so it would work they way
we needed it to.

It boils down to one thing:

1) Do you know your customers?  Do you know what they need? Have you dug
past what they asked for to understand what they really meant? Are you
absolutely sure you know what they need?

*If* you know the users' requirements and no subset of that requirement will
do, then I have no problem with a large overarching story, but it's not one
I would use as a developer.  Rather, I'd break it down into as many
reasonable chunks as possible, likely based on the underlying technical
pieces needed to support the user story.

Do everything you can to know your customer.

--Kaleb

http://twitter.com/kalebpederson
http://kalebpederson.com

[adam_peter.knight]

I agree - I apologise I was in danger of missing a train and so only
half responded to Steve's question. We are only just starting out in the
process of delivering requirements specifically requested by the users,
previously we have been trying to predict what the market required. Now
we have some good customer relationships established we can be much more
customer driven (which is, after all, the main focus of Agile
development). We haven't been stung as yet but it is early days.

Adam.
--- In agile-testing@..., Kaleb Pederson
<kaleb.pederson@...> wrote:

>
> Adam,
>
> Thanks for the detailed responses to my earlier message.  I have one
> comment  which is inline below and directly related to Steven Gordon's
> question:
>
> On Fri, Oct 9, 2009 at 10:05 AM, adam_peter.knight <
> adam.knight@... wrote:
>
> >
> >
> > Thanks for the response..
> >
> > --- In agile-testing@..., Steven Gordon sgordonphd@
> > wrote:
> > >
> > > What has the customer's experience been with big bang, ambiguous,
> > > all-or-nothing requirements? Has the customer been happy with the
> > results?
> > > How often do they say what they got was not what they asked for?

How
> > often
> > > do they say they got what they asked for but it does not really
work well
> > > for them? How often do they ask for changes in what they got?
> >
> > Our customers prefer infrequent releases with large scale product
> > improvements due to the overheads that they have in validating and
rolling
> > out each new version (our customers integrate our product into their
own,
> > and each has multiple installations of their own product so
upgrading is an
> > expensive process)
> >
>
> I thought Steve was asking a different question, one that you didn't
answer.
>
> Isn't the real question about the requirements rather than the
> implementation?  Having worked in an enterprise environment for a
number of
> years, I didn't want to deal with frequent system implementations, but
I
> desperately wished I could be more involved in requirement
definitions.
> Whenever one of the newly implemented requirements didn't do what we
needed,
> it was my job to make modifications to the system so it would work
they way
> we needed it to.
>
> It boils down to one thing:
>
> 1) Do you know your customers?  Do you know what they need? Have you
dug
> past what they asked for to understand what they really meant? Are you
> absolutely sure you know what they need?
>
> *If* you know the users' requirements and no subset of that
requirement will
> do, then I have no problem with a large overarching story, but it's
not one
> I would use as a developer.  Rather, I'd break it down into as many
> reasonable chunks as possible, likely based on the underlying
technical
> pieces needed to support the user story.
>
> Do everything you can to know your customer.
>
> --Kaleb
>
> http://twitter.com/kalebpederson
> http://kalebpederson.com
>

[Adrian Howard]

On 9 Oct 2009, at 12:20, Hubert Matthews wrote:

> I've seen agile teams get bogged down by trying to write deliverable
> code before they know what it is that they are trying to write.

That can happen. I'd put that down to a Customer/PO problem myself  
there... It's a variation of the problem of the PO asking the rest of  
the team to develop the wrong thing. Both dev and Customer need some  
courage and mutual respect to get around that.

>  I've
> also seen them get stuck when there have been big blockers such as the
> unavailability of test data from another system.

Also problematic. I've seen some interesting solutions to that sort of  
problem though (e.g. developing a couple of the possible solutions in  
parallel - then dropping the one that didn't get instantiated. Anybody  
else tried something like that?)

But like the first issue you raised - I'm not really seeing that as a  
conflict with Agile in particular. Any development approach isn't  
going to work well when you don't know what you're developing against:-)

> Yes, agile is good at learning in the small but for longer or larger
> research then we may need to step away from the keyboard for a moment
> and do non-code-oriented iterations or proof-of-concept
> non-deliverable work.

That's fine - but seems to work well with agile in my experiences.  
We're happy to do spikes. We're happy (or should be) to let the  
Customer/PO figure out what they want in whatever way they wish. I've  
worked, while wearing my UX research hat, with agile teams and it all  
seems to have gone smoothly.

> Another case is when you have some major
> upheaval or a large feature change where you need to take the whole
> thing apart and put it back together again later.  This sort of work
> rarely has stable intermediate forms and so practices like CI don't  
> work.

I've found problems of that sort have fallen into two camps for me:
1) After thinking about the problem we've managed to find a way of  
incrementally migrating it and keeping CI up and running
2) Times when (1) has seemed impossible / too expensive... only find  
to it probably wasn't with the benefit of hindsight from the evil  
things that happened when we tried to do it the other way...

There probably is a third camp - but its not happened to me yet. I  
suspect it may be less common than many people think.

I keep doing (2). Must stop doing that :-)

> Incremental delivery of value is important.  We just have to have a
> clear idea that value does not always mean code.  Sometimes research,
> prototypes, plans, etc are more valuable.


I agree that research, etc. is important. Love it to death.

Need a prototype? The agile team are really good at building that for  
you. Because of that whole "embrace change" stuff folk generally seem  
more acceptance of experimentation and have more of a willingness to  
discard bad solutions. Because agile teams have an incremental  
discovery approach to building the design of the code - they seem to  
understand more clearly that research is a necessary and incremental  
process.

My experience has been that agile fits much better with the research  
side than non-agile approaches - but that's obviously not been your  
experience... so I'd love to explore the difference.

My research stuff has mostly been from the UX side - user research,  
user testing, ideation, etc. and that's generally worked better for me  
than with more traditional non-agile teams. Has yours been in a  
different domain?

Cheers,

Adrian
--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Voris, John]

> We just have to have a clear idea that value does not always mean
code. Sometimes research, prototypes, plans, etc are more valuable.
 
I agree with what everyone has stated before.  But when I hear that your
charter for the sprint to devise a policy-generator for the database
purge criteria without being "first-hand to the actual data", I get
worried and may be looking at a failed effort, if not in a failure of
delivery of some code to perform a set of purges, at least it will be
sub-optimized area that may need to be revised.  I for one doubt that
the customer has (or could possibly) predict every scenario that they
will need.  And I absolutely agree with the notion that the deliverable
of a policy is more than just code, it is the group-think "wisdom of
crowds" to come up with better algorithms and handling of scenarios.
 
It is just in my experience that "Concrete Examples" that are close to
reality (and within the day-to-day management of the real data and real
situations as they arise) are what is needed to move the conversation
along, recognizing that the conversation is a deliverable.  Being as you
describe - quite set apart from the customer who can set their own
policy - will never think of all situations and data dependencies.  You
state that the data schema is outside your reach, and that too is a
project smell of a possible future roadblock.
 
 

[Hubert Matthews]

Adrian Howard wrote:
> My experience has been that agile fits much better with the research  
> side than non-agile approaches - but that's obviously not been your  
> experience... so I'd love to explore the difference.

Agile should be good at research but I've found that people seem to
think that deliverable code is the only valid output (you snipped my
comment about delivering value and not just code).  Research is not
acknowledged as such; it's just supposed to happen when people write
code.  After all, "the code is the design" seems to imply that you
don't need design, planning or documentation, and "we'll refactor
later" seems to be an excuse for not thinking or enquiring first.
Furthermore "a story is just the start of a conversation" so no
forethought is required.  This isn't how good agile should be but I've
seen too much so-called agile.  After all, "we're doing iterations so
we must be agile"!

Not all that claims to be agile is agile.  As a consultant I've seen
more "cargo cult" agile than real agile.

--
Hubert Matthews         http://www.oxyware.com/
Software Consultant     hubert@...

[Steven Gordon-2]

In partial support of your point, I ran a lab at a university for 3 years
(until its grant ran out) where teams of part-time student workers supported
university research projects using an agile approach.

What we found was that our clients really liked being able to change
software requirements every month because they decided that exploring an
alternative approach would add the most value to the research the next month
or their research would often discover (sometimes due to the software) that
a different approach would work better.

This was universally the case where the research was /not/ in computer
science.  However, the one client who was doing computer science research
found little value in having ideas developed in an agile fashion.

In short, if the research is in the problem domain and the code just
implements or supports that research, then a good PO should be able to
leverage agile development to support doing that research in that problem
domain.  However, if the research domain is /software/, then the lines
between the what and the how are blurred, making clashes in roles, authority
and responsibilities likely to add considerable conflict and friction.

On Mon, Oct 12, 2009 at 6:55 AM, Hubert Matthews <hubert@...> wrote:

>
>
> Adrian Howard wrote:
> > My experience has been that agile fits much better with the research
> > side than non-agile approaches - but that's obviously not been your
> > experience... so I'd love to explore the difference.
>
> Agile should be good at research but I've found that people seem to
> think that deliverable code is the only valid output (you snipped my
> comment about delivering value and not just code). Research is not
> acknowledged as such; it's just supposed to happen when people write
> code. After all, "the code is the design" seems to imply that you
> don't need design, planning or documentation, and "we'll refactor
> later" seems to be an excuse for not thinking or enquiring first.
> Furthermore "a story is just the start of a conversation" so no
> forethought is required. This isn't how good agile should be but I've
> seen too much so-called agile. After all, "we're doing iterations so
> we must be agile"!
>
> Not all that claims to be agile is agile. As a consultant I've seen
> more "cargo cult" agile than real agile.
>
> --
> Hubert Matthews http://www.oxyware.com/
> Software Consultant hubert@... <hubert%40oxyware.com>
>  
>

[Hubert Matthews]

Steven Gordon wrote:
> In short, if the research is in the problem domain and the code just
> implements or supports that research, then a good PO should be able to
> leverage agile development to support doing that research in that
> problem domain.  However, if the research domain is /software/, then the
> lines between the what and the how are blurred, making clashes in roles,
> authority and responsibilities likely to add considerable conflict and
> friction.

There is indeed a difference between research about the problem and
research about the best solution to the problem.  My posts were aimed
more at the latter and have encountered some of the issues you
mentioned.  Companies such as Toyota will evaluate multiple solution
approaches in parallel before selecting one and then moving to the
"flawless execution" stage.  Most projects that I've seen pick a
solution approach early on, stick with it and push it as far as they
can until they have either to refactor their way out of it or rewrite
the project to move forward.  They can also arrive at the "if your
problem doesn't fit our solution then you have an invalid problem"
world view.  Focusing on a single solution approach and not focusing
on the problem domain is a trap lots of developers fall into.  TDD and
up-front test definition helps to mitigate this as it forces an
external problem-focused view.  Some time spent on learning what
architecture is the most appropriate might not be a bad thing either
(if more than a little too heretical for a lot of agilistas).

--
Hubert Matthews         http://www.oxyware.com/
Software Consultant     hubert@...

[Steven Gordon-2]

On Mon, Oct 12, 2009 at 9:06 AM, Hubert Matthews <hubert@...> wrote:
>
> . . .
>
> Focusing on a single solution approach and not focusing
> on the problem domain is a trap lots of developers fall into. TDD and
> up-front test definition helps to mitigate this as it forces an
> external problem-focused view.

Feedback from frequent deliveries provides the opportunity to see if
the selected solution is not working for the intended audience.  Not
working in the technical sense is a different story, but frequent
feedback also helps.

> Some time spent on learning what
> architecture is the most appropriate might not be a bad thing either
> (if more than a little too heretical for a lot of agilistas).

My reaction whenever I hear this is coloured by my pre-agile
experience of architecture work being entirely theoretical and based
on the latest fads and available frameworks.

As an 'agilista', I much prefer to learn what architecture choices are
most appropriate by implementing alternatives on slices of real domain
problems.  Delivering working software at the same time in order to
garner feedback on whether the requirements are understood the same by
everybody and actually correct is a nice side-effect of doing this
instead of architecting on paper.

I also advocate implementing the code that uses the architecture to be
as decoupled from the architecture as possible to reduce the cost of
changing the architecture if something we learn later makes that the
best choice.

SteveG

>
> --
> Hubert Matthews http://www.oxyware.com/
> Software Consultant hubert@...