headers
Cass Dalton | 4 Jul 2012 03:17
Picon

How to split a story that doesn't have customer value when split

In my continuing journey to understand the art of writing user stories, I'd like to present the following scenario that is analogous to the type of situation I deal with in our group.

Lets say your team is contracted to build a riding mower.  The main user story is "as a homeowner, I want to mow my lawn without pushing a mower". There will obviously be stories for features like better turning radius and adjustable blade height, but the first story that provides actual customer value (just having a riding mower to cut the lawn) will require a sizable team working multiple sprints just to get the mower working.  There are the wheels, tires, multiple components in the engine, the chassis, the blade, the steering, etc.  The system is so complex and the actual use case is so simple, that it feels like there is no good way to break up the first main user story.  You could write a story for the wheels (designing, machining, etc), and a story for the chassis, but these types of stories on their own don't provide any customer value.  You're supposed to slice up the big stories such that you get thin slices of all the layers in the cake, but in this type of complex system, I don't understand how you can do that.
The projects I work on are like this.  There is a single primary feature that requires a lot of work (i.e. multiple sprints) just to get a system that provides minimal customer value.  Once you have that, many of the follow on features start to roll off in good user stories.

So how do you split up these types of epics?


__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
RonJeffries | 8 Jul 2012 17:56
Picon
Favicon
Gravatar

Re: How to split a story that doesn't have customer value when split

Hello, Cass,

On Jul 3, 2012, at 9:17 PM, Cass Dalton wrote:

The projects I work on are like this.  There is a single primary feature that requires a lot of work (i.e. multipl e sprints) just to get a system that provides minimal customer value.  Once you have that, many of the follow on features start to roll off in good user stories.

So how do you split up these types of epics?

Are you building lawnmowers? In that case I don't know. If you happen to be building software, please tell us a real software story. We might be able to help with that.

Thanks,

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell


__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Laurent Bossavit | 8 Jul 2012 21:53

Re: How to split a story that doesn't have customer value when split

Hi Ron,

> Are you building lawnmowers? In that case I don't know. If you happen to be building software, please tell
us a real software story. We might be able to help with that.

Actually I kind of disagree with you there - the mower example is sort of interesting to think about. Got *me*
thinking, anyway, for which I'm grateful to Cass. (Hi Cass! Thanks!)

I immediately started thinking of at least one implementation, probably less that one sprint long, that
would work for small enough lawns - involving a length of strong nylon wire, a motor and a spike (actual
spike, not the XP kind of spike).

Then I tried to stop myself from thinking implementation first - after all, Agile teaches us to first ask
better questions about where the business value is coming from.

It teaches us to push back against "requirements" that over-specify the "what" - in this case "a riding
mower", and instead focus on the "how" and its "why". So instead I'd start asking questions about what kind
of customers we are targeting who don't want to push a mower, maybe generate alternatives to the "riding" solution.

I may even leaf through one of the Lean Startup books again and ask how we're planning to compete with any
number of existing riding mowers, and whether that plan is strategically sound; I might start thinking
about "minimum validated learning" and similar buzzwords.

And...

There's a nagging feeling that my reaching for these ideas is confirmation bias at work: the big constraint
in the OP's problem statement is that it's hard to build a riding mower in small slices, and my first relfex
was to find some way of relaxing that constraint... and so I find myself trying to justify relaxing the constraint.

Yet, on considered reflection, this seems a more useful path to me than starting with "Assume we have
requirements such that we just can't build in small slices; then how do we build in small slices?" If that's
the problem statement, *something's* got to give - either the small slices, or the requirements. That's
the nub of the question as I see it.

(Writing good user stories is not an "analysis technique", per the age-honored distinctions made in
Software Engineering, where you take the requirements in some other form as an "input" and somehow crank
out your user stories on that basis. Agile rejects these distinctions, because age-honored as they are,
they seem to be the software development equivalent of the epicycles.)

So my advice to Cass, to get out of the seeming paradox, is "question the requirements". Ask "why". It's what
we do.

Cheers,
Laurent

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
Michael James | 8 Jul 2012 22:01
Picon

Re: How to split a story that doesn't have customer value when split

I guess we could start with a scythe ( http://online.wsj.com/article/SB10001424052702304782404577490583379647566.html ), then build a manual push mower, then put a motor on the blades, and eventually work up to a riding mower.  Or maybe a goat ... is Scrum intended for goat herding?

It's usually not feasible to do this with physical products because the cost of change curve is more severe than it can be with software development using modern techniques.

--mj
(Michael)


On Jul 8, 2012, at 12:53 PM, Laurent Bossavit wrote:

 

Hi Ron,

> Are you building lawnmowers? In that case I don't know. If you happen to be building software, please tell us a real software story. We might be able to help with that.

Actually I kind of disagree with you there - the mower example is sort of interesting to think about. Got *me* thinking, anyway, for which I'm grateful to Cass. (Hi Cass! Thanks!)

I immediately started thinking of at least one implementation, probably less that one sprint long, that would work for small enough lawns - involving a length of strong nylon wire, a motor and a spike (actual spike, not the XP kind of spike).

Then I tried to stop myself from thinking implementation first - after all, Agile teaches us to first ask better questions about where the business value is coming from.

It teaches us to push back against "requirements" that over-specify the "what" - in this case "a riding mower", and instead focus on the "how" and its "why". So instead I'd start asking questions about what kind of customers we are targeting who don't want to push a mower, maybe generate alternatives to the "riding" solution.

I may even leaf through one of the Lean Startup books again and ask how we're planning to compete with any number of existing riding mowers, and whether that plan is strategically sound; I might start thinking about "minimum validated learning" and similar buzzwords.

And...

There's a nagging feeling that my reaching for these ideas is confirmation bias at work: the big constraint in the OP's problem statement is that it's hard to build a riding mower in small slices, and my first relfex was to find some way of relaxing that constraint... and so I find myself trying to justify relaxing the constraint.

Yet, on considered reflection, this seems a more useful path to me than starting with "Assume we have requirements such that we just can't build in small slices; then how do we build in small slices?" If that's the problem statement, *something's* got to give - either the small slices, or the requirements. That's the nub of the question as I see it.

(Writing good user stories is not an "analysis technique", per the age-honored distinctions made in Software Engineering, where you take the requirements in some other form as an "input" and somehow crank out your user stories on that basis. Agile rejects these distinctions, because age-honored as they are, they seem to be the software development equivalent of the epicycles.)

So my advice to Cass, to get out of the seeming paradox, is "question the requirements". Ask "why". It's what we do.

Cheers,
Laurent




__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Laurent Bossavit | 8 Jul 2012 22:07

Re: How to split a story that doesn't have customer value when split

> Or maybe a goat ...

Goats are a *great* idea!

They're what Google uses (*) in Mountain View: http://googleblog.blogspot.fr/2009/05/mowing-with-goats.html

If they're good enough for Google surely that should make *anyone* think twice about dismissing the idea. :)

Cheers,
Laurent

(*) OK, "has used at least once" is more accurate

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
Otis Bricker | 8 Jul 2012 22:15
Picon

Re: How to split a story that doesn't have customer value when split

Wouldn't there be value in a set of stories like:
1. As a Homeowner, I want to be able to cut my grass.
All that need is a pair of shears.
2. As a HO, I want to cut grass without much hand effort
Maybe a push mower?
3. As a HO, I want to cut grass without much much effort
4. As a HO, I want to cut LARGE lawns without my legs getting tired.

Seems the initial story assumes an already existing Tech Stack, the 
mower it mentions, but then ignores it completely.

Otis

On 7/8/2012 3:53 PM, Laurent Bossavit wrote:
> Hi Ron,
>
>> Are you building lawnmowers? In that case I don't know. If you happen to be building software, please tell
us a real software story. We might be able to help with that.
> Actually I kind of disagree with you there - the mower example is sort of interesting to think about. Got
*me* thinking, anyway, for which I'm grateful to Cass. (Hi Cass! Thanks!)
>
> I immediately started thinking of at least one implementation, probably less that one sprint long, that
would work for small enough lawns - involving a length of strong nylon wire, a motor and a spike (actual
spike, not the XP kind of spike).
>
> Then I tried to stop myself from thinking implementation first - after all, Agile teaches us to first ask
better questions about where the business value is coming from.
>
> It teaches us to push back against "requirements" that over-specify the "what" - in this case "a riding
mower", and instead focus on the "how" and its "why". So instead I'd start asking questions about what kind
of customers we are targeting who don't want to push a mower, maybe generate alternatives to the "riding" solution.
>
> I may even leaf through one of the Lean Startup books again and ask how we're planning to compete with any
number of existing riding mowers, and whether that plan is strategically sound; I might start thinking
about "minimum validated learning" and similar buzzwords.
>
> And...
>
> There's a nagging feeling that my reaching for these ideas is confirmation bias at work: the big
constraint in the OP's problem statement is that it's hard to build a riding mower in small slices, and my
first relfex was to find some way of relaxing that constraint... and so I find myself trying to justify
relaxing the constraint.
>
> Yet, on considered reflection, this seems a more useful path to me than starting with "Assume we have
requirements such that we just can't build in small slices; then how do we build in small slices?" If that's
the problem statement, *something's* got to give - either the small slices, or the requirements. That's
the nub of the question as I see it.
>
> (Writing good user stories is not an "analysis technique", per the age-honored distinctions made in
Software Engineering, where you take the requirements in some other form as an "input" and somehow crank
out your user stories on that basis. Agile rejects these distinctions, because age-honored as they are,
they seem to be the software development equivalent of the epicycles.)
>
> So my advice to Cass, to get out of the seeming paradox, is "question the requirements". Ask "why". It's
what we do.
>
> Cheers,
> Laurent
>
>

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
George Dinwiddie | 8 Jul 2012 22:32
Favicon

Re: How to split a story that doesn't have customer value when split

Laurent,

On 7/8/12 3:53 PM, Laurent Bossavit wrote:
> Hi Ron,
>
>> Are you building lawnmowers? In that case I don't know. If you
>> happen to be building software, please tell us a real software
>> story. We might be able to help with that.
>
> Actually I kind of disagree with you there - the mower example is
> sort of interesting to think about. Got *me* thinking, anyway, for
> which I'm grateful to Cass. (Hi Cass! Thanks!)

That may be, but I've found that mechanical metaphors generally aren't 
very useful to people learning how to split user stories. Software is 
much more malleable than most construction materials. And software is 
more like the plans or models of the final product--a friend who has 
taught parametric mechanical modeling tells me that working from that 
viewpoint is a new thing to most mechanical designers, too.

So, my initial reaction is the same as Ron's. If he hadn't responded as 
he did, I would have asked a very similar question.

  - George

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
Permalink | Reply |
headers
Otis Bricker | 13 Jul 2012 21:39
Picon

Re: How to split a story that doesn't have customer value when split

"One problem is that the suggestion results in a complete rewrite of the system each time.  Or alternatively, a set of increasingly more complex prototypes."

Not necessarily. I don;t see a partial solution as a prototype. When you start, you have nothing that cuts grass. Even having the clippers provides some value since it improves over breaking off each blade by hand.

While you might end up with a something that requires major rework, you might just end up somewhere you didn't expect to go.
Clippers-> Row of clippers driven by push wheels( good for even ground)-> Clippers on springs( uneven Ground)->Multiple Rows at different heights(better mulching)->Motor Driven-> Size shrink and semi-random motion generator(autonomous operation)->???

Like I said, your original story assumed you wanted to ride on a mower. Isn't that a solution not a story? What was it you wanted to accomplish? I think it was more along the lines of : As a Homeowner, I want to cut my grass with no effort. To get to that story, you can have several that are less  demanding.

Even if it was the real story, it assumes that there is a self-propelled mower since you refer to it. So the only work left is to add the steering and a seat.
 
On 7/8/2012 5:20 PM, Cass Dalton wrote:
Laurent,
I agree that we constantly want to ask "why" especially when our customers seem to already have a solution in mind.  I attempt to do this at work constantly.  I have redirected customers to better solutions when they already had a solution in mind.  I may have written my initial user story poorly, but my intention was to write a user story that truly represented exactly what the user needed so that we could focus on my problem.  The user story was not the important part of the analogy for me.  It was to be assumed that there was some user need that couldn't easily be implemented in a single implementation.  As someone with only a traditional waterfall background, my initial reaction usually would have been to write a story for the wheels, a story for the engine, a story for the chassis, etc.

The suggestion from Otis is interesting in that it breaks up what I thought was an atomic need into incremental needs.  I have done that sort of thing at work without really realizing that that was what I was doing.  One problem is that the suggestion results in a complete rewrite of the system each time.  Or alternatively, a set of increasingly more complex prototypes.

Ron,
OK, so let me try to make a software analogy.

One of the difficulties of the systems my company builds is that they are real time systems with multiple software and hardware components.  
Lets say that you have a system that has to interact with an existing system.  It has to intercept events that are passing through the system.  Some events are notifications, some events are compact data streams.  Each data stream has a preceding notification.  There are some notifications/data streams that we want to process, some that we don't.  There are post-processing plug-ins.  Each plug-in is interested in a different set of notifications.  These plug-ins, the management of the data and messages, and everything new aside from a minimal amount of code have to live on one or more separate machines (a non-negotiable political customer constraint).  The first plug-in to be used requires a huge amount of signal processing to get any information out of the data stream.  For example, lets assume that we have to parse an HTML stream from only the voltages as seen by the network interface card.  But we don't have a NIC, we don't have access to any of the existing ethernet driver code, TCP/IP network stack, HTTP libraries, etc.  We have to write all that from scratch.

The user need is that they want to automatically parse the HTML from these data streams.  To get this done, we have to interface to the existing system, build something that will intelligently route the data to the right post-processor, something that will make sure that the right processor is installed (we're always striving for deliverable code at the end of each sprint), and we need the processor.  I know that I have already assumed some of the system design in this description, but it is for the purpose of describing the complexity of the system.  Lets just assume that this system design is what the team decided was the best solution.  Even by taking liberties like hardcoding the post-processor to use and things like that, it will still take at least three sprints to come close to anything that they customer will see as value.

Relating back to the scythe example, we have some something akin to an offline version of the post-processor and demonstrating that to the customer.  But it still takes multiple sprints just to build that, and that solution only goes so far:  If you build them a scythe as a stepping stone to a lawn mower, what value have you gained?  Is the scythe a technological step towards a lawn mower?  If so, then you have value.  If not, then you have built something that you have to throw away.  That's OK if you learned something from the scythe about the customer's needs.  But in my example, that's akin to taking a string of the ethernet voltages and manually translating them to IP packets, manually translating the string of IP packets to a TCP connection, etc on to the HTML stream.  There's some customer value in that you are understanding the customer's need, but there's still a lot of work to do to build the actual system.



On Sun, Jul 8, 2012 at 4:32 PM, George Dinwiddie <lists <at> idiacomputing.com> wrote:
 

Laurent,



On 7/8/12 3:53 PM, Laurent Bossavit wrote:
> Hi Ron,
>
>> Are you building lawnmowers? In that case I don't know. If you
>> happen to be building software, please tell us a real software
>> story. We might be able to help with that.
>
> Actually I kind of disagree with you there - the mower example is
> sort of interesting to think about. Got *me* thinking, anyway, for
> which I'm grateful to Cass. (Hi Cass! Thanks!)

That may be, but I've found that mechanical metaphors generally aren't
very useful to people learning how to split user stories. Software is
much more malleable than most construction materials. And software is
more like the plans or models of the final product--a friend who has
taught parametric mechanical modeling tells me that working from that
viewpoint is a new thing to most mechanical designers, too.

So, my initial reaction is the same as Ron's. If he hadn't responded as
he did, I would have asked a very similar question.

- George

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------






__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Michael James | 13 Jul 2012 21:55
Picon

Re: How to split a story that doesn't have customer value when split

On Jul 8, 2012, at 2:20 PM, Cass Dalton wrote:

Relating back to the scythe example, we have so me something akin to an offline version of the post-processor and demonstrating that to the customer.  But it still takes multiple sprints just to build that, and that solution only goes so far:  If you build them a scythe as a stepping stone to a lawn mower, what value have you gained?  Is the scythe a technological step towards a lawn mower?  If so, then you have value.  If not, then you have built something that you have to throw away.  That's OK if you learned something from the scythe about the customer's needs.  But in my example, that's akin to taking a string of the ethernet voltages and manually translating them to IP packets, manually translating the string of IP packets to a TCP connection, etc on to the HTML stream.  There's some custom er value in that you are understanding the customer's need, but there's still a lot of work to do to build the actual system.

As I see it, gaining a true understanding the customer's needs (through exploratory action) is the real benefit of iterative development, justifying the technical rework you're describing.  I've come to see the technical effort as a smaller and smaller part of the equation, especially in the software realm using modern techniques that tend to flatten out the cost of change curve.  Product development is knowledge creation.

--mj



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Otis Bricker | 14 Jul 2012 05:55
Picon

Re: How to split a story that doesn't have customer value when split

On 7/8/2012 5:20 PM, Cass Dalton wrote:
> For example, lets assume that we have to parse an HTML stream from 
> only the voltages as seen by the network interface card.  But we don't 
> have a NIC, we don't have access to any of the existing ethernet 
> driver code, TCP/IP network stack, HTTP libraries, etc.  We have to 
> write all that from scratch.

I missed this comment in my first reading.

IF there are none of the above, why would you have to parse HTML? No one 
is capable of sending and and it would likely have never come about 
without the supporting items you are now requiring your project to create.

Again, it seems like you are assuming a solution based on existing 
technology but then denying yourself the benefit of that tech. It might 
well be that the problem you are solving would be better answered in 
some other way. If this is truly an ALL NEW project, then there would be 
value in being able to transmit data remotely first, even between two 
fixed machines. That may not be enough of a feature set to make a 
product, but that isn't what a story is about.

Otis

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
Cass Dalton | 14 Jul 2012 16:13
Picon

Re: How to split a story that doesn't have customer value when split

If we were really rewritting HTTP and the network stack from scratch, you would be correct.  We and our customer would have a horrible business model.  But its just an analogy.  The lawnmower analogy didn't go over well and Ron wanted a story that related to software.  Since I can't describe a real customer story for various reasons, I fabricated one that would convey the complexity that we typically have to deal with and that would convey the issue that I wanted to ask the group about.

I'd like to thank everyone in the group that has given ideas and suggestions.  This has really helped.  I'm learning that in agile, there is a huge difference between knowing the path and walking the path.  User stories especially are an art that takes experience, practice, and determination.  One of the biggest impediments in my most recent experiment with agile was the user story writing.  The stories were too large, had poor definitions of done, and read like requirements.  Big heavy waterfall is all I've ever known and I've come to understand that an agile process is only 20% of the answer.  The other 80% is the culture and organizational philosophy that has to go with it.

On Jul 13, 2012 11:55 PM, "Otis Bricker" <obricker <at> comcast.net> wrote:
On 7/8/2012 5:20 PM, Cass Dalton wrote:
> For example, lets assume that we have to parse an HTML stream from
> only the voltages as seen by the network interface card.  But we don't
> have a NIC, we don't have access to any of the existing ethernet
> driver code, TCP/IP network stack, HTTP libraries, etc.  We have to
> write all that from scratch.

I missed this comment in my first reading.

IF there are none of the above, why would you have to parse HTML? No one
is capable of sending and and it would likely have never come about
without the supporting items you are now requiring your project to create.

Again, it seems like you are assuming a solution based on existing
technology but then denying yourself the benefit of that tech. It might
well be that the problem you are solving would be better answered in
some other way. If this is truly an ALL NEW project, then there would be
value in being able to transmit data remotely first, even between two
fixed machines. That may not be enough of a feature set to make a
product, but that isn't what a story is about.

Otis



------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Charles Bradley - Scrum Coach CSP CSM PSM I | 24 Jul 2012 17:13

Re: How to split a story that doesn't have customer value when split

Cass,

Thanks for your patience with us on the list.  We often miss a word or two and completely misunderstand the purpose of someone's email.  Thank you for emphasizing that your contrived example is indeed contrived.  Thank you also for coming up with such a complex contrived example, and I hope it serves your purpose.  Some on the list may doubt the complexity of what you're dealing with, but I do not.  It is very clear that you are trying very hard to "walk the Agile path," and this community supports people just like you(for free) because we know it can be hard at times, and we believe very much in wha t you're doing.
1.  It definitely appears as if you have a complex problem on your hands.  If it's a brand new system, and you have figured out the tiniest, thinnest, smallest slice, all(or largely most of) the way through the system that provides some miniscule amount of shippable functionality, then how long, in days of duration, does your team estimate it would take that to do?  (Assume that the entire team worked on the one story)(If you don't know the answer to this, then an educated guess on your part will do for now for our discussion purposes.)

2.  Is the entire product large enough, and/or delivery time frame short enough, such that it make sense to split into more than one team of 3-9 developers?

-------
Charles Bradley
http://www.ScrumCrazy.com


From: Cass Dalton <cassdalton73 <at> gmail.com>
To: scrumdevelopment <at> yahoogroups.com
Sent: Saturday, July 14, 2012 8:13 AM
Subject: Re: [scrumdevelopment] How to split a story that doesn't have customer value when split



If we were really rewritting HTTP and the network stack from scratch, you would be correct.  We and our customer would have a horrible business model.  But its just an analogy.  The lawnmower analogy didn't go over well and Ron wanted a story that related to software.  Since I can't describe a real customer story for various reasons, I fabricated one that would convey the complexity that we typically have to deal with and that would convey the issue that I wanted to ask the group about.
I'd like to thank everyone in the group that has given ideas and suggestions.  This has really helped.  I'm learning that in agile, there is a huge difference between knowing the path and walking the path.  User stories especially are an art that takes experience, practice, and determination.  One of the biggest impediments in my most recent experiment with agile was the user story writing.  The stories were too large, had poor definitions of done, and read like requirements.  Big heavy waterfall is all I've ever known and I've come to understand that an agile process is only 20% of the answer.  The other 80% is the culture and organizational philosophy that has to go with it.
On Jul 13, 2012 11:55 PM, "Otis Bricker" <obricker <at> comcast.net> wrote:
On 7/8/2012 5:20 PM, Cass Dalton wrote:
> For example, lets assume that we have to parse an HTML stream from
> only the voltages as seen by the network interface card.  But we don't
> have a NIC, we don't have access to any of the existing ethernet
> driver code, TCP/IP network stack, HTTP libraries, etc.  We have to
> write all that from scratch.

I missed this comment in my first reading.

IF there are none of the above, why would you have to parse HTML? No one
is capable of sending and and it would likely have never come about
without the supporting items you are now requiring your project to create.

Again, it seems like you are assuming a solution based on existing
technology but then denying yourself the benefit of that tech. It might
well be that the problem you are solving would be better answered in
some other way. If this is truly an ALL NEW project, then there would be
value in being able to transmit data remotely first, even between two
fixed machines. That may not be enough of a feature set to make a
product, but that isn't what a story is about.

Otis



------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/







__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
RonJeffries | 15 Jul 2012 01:59
Picon
Favicon
Gravatar

Re: How to split a story that doesn't have customer value when split


On Jul 8, 2012, at 5:20 PM, Cass Dalton wrote:

One of the difficulties of the systems my company builds is that they are real time systems with multiple software and hardware componen ts.  

OK ...

Lets say that you have a system that has to interact with an existing system.  It has to intercept events that are passing through the system.  Some events are notifications, some events are compact data streams.  Each data stream has a preceding notification.  

Yes. Doubtless each can be seen as some string of bytes that can be told from the others, according to some protocol. This makes me foresee a split along different events, doing one at a time.

There are some notifications/data streams that we want to process, some that we don't.  

Yes. So an early story might be to show the ability to partition them into the ones we want and the ones we do not want.

There are post-processing plug-ins.  Each plug-in is interested in a different set of notifications.  These plug-ins, the management of the data and messages, and everything new aside from a minimal amount of code have to live on one or more separate machines (a non-negotiable political customer constraint).  

OK. Seems clear that each plug-in is a separate story, quite possibly even a separate product. They do not all have the same value, almost certainly, and should probably be done with the high-value ones first. So here again,we see some things to split out.iv>
The first plug-in to be used requires a huge amount of signal processing to get any information out of the data stream.  For example, lets assume that we have to parse an HTML stream from only the voltages as seen by the netwo rk interface card.  But we don't have a NIC, we don't have access to any of the existing ethernet driver code, TCP/IP network stack, HTTP libraries, etc.  We have to write all that from scratch.

Congratulations for finding hardware for which there is no network stack. These, too, seem like separate projects, not all part of one giant story.

The HTML stream, as someone already mentioned, sounds a lot like a pre-made design decision. Perhaps it is part of the contract. If so, then there is probably some agreed or predefined protocol. At a guess it might be better to think of this as XML rather than HTMl. Either way, one does not need an HTTP library to produce HTML. print "<head></head><body></b ody>" might be my first cut at the library. I would let the library emerge.

As for the voltages from the NIC, the hardware will surely have instructions for reading those bits, deciding what voltages to request, and so on. This, too, will be a small protocol that is readily partitioned. Last time I did something like that, I wrote a small assembler routine that set the right values on the pins, read the resulting outputs. Had a timing loop in it, if I recall. Perhaps a more modern computer would raise an interrupt when the values were ready. Either way, a day's work to read the first value. After that, one just grows more and more capability.

It begins to become clear that there are lots of separable project bits which may want to run asynchronously in time, maybe even on different hardware / software platforms. I'd negotiate simple starting protocols between separate teams, if I had them. Each team would mock one side of the interface, with tests, so that when the other team had some of the interface "ready" there would be tests available for them to work through. Regular meetings would update the protocol and tests. The teams would work in lock step or async as seemed best.

The user need is that they want to automatically parse the HTML from these data streams.  To get this done, we have to interface to the existing system, build something that will intelligently route the data to the right post-processor, something that will make sure that the right processor is installed (we're always striving for deliverable code at the end of each sprint), and we need the processor.  

You have just described a few more separable bits right here. For these, too, we can provide mock objects w ith tests to manage the interfaces. We can, for example, create a mocked-up HTML stream and feed it to the processor that parses it. That will show the extent to which the parsing works. Naturally, since the message in HTML has various parts, the parsing project can work on them one after another.

Similarly, we can mock the "intelligent routing", essentially hard-coding the processor choice. If I understood your description, the processor choice is embedded in the HTML? Anyway it will be somewhere in some protocol. Wherever it is, we identify a second message that needs to go to a different processor. We feed that with two streams and test whether it selects the right one. Now we have a slightly more mature "intelligent routing". Then we pick another protocol to select on.

I know that I have already assumed some of the system design in this description, but it is for the purpose of describing the complexity of the system.  Lets just assume that this system design is what the team de cided was the best solution.  Even by taking liberties like hardcoding the post-processor to use and things like that, it will still take at least three sprints to come close to anything that they customer will see as value.

I don't think that's the case. If your team is any good, I'd wager we could produce something that would show the customer real progress in a single Sprint. Would they ship it? No, certainly not. Would they use it? Not yet. But they would see a tiny, embryonic, running system, where we could point to the tiny embryonic elements that we had built, and to the holes were the ones were that we had skipped over entirely. 

This system might have a few component stories, perhaps along these lines :
  • Read values from Register A of the NIC
  • Detect Protocol A and dispatch to Processor A
  • In Processor A, read simple HTML message and correctly identify it
  • ... and so on

Whatever work needs to be done is in service of the customer need. Whatever work is going to be done, we can and should make parts of it work every day, not just ever week or month. Therefore, we choose and define the work so that its value to the customer is understandable by the customer.

This reminds me of a story. A team I was working with had built a big system that processed mainframe data on local processors in the user site. One of the things that had to be done was to FTP the data from the mainframe over to the locals, in the middle of the night. They asked me if they could just write a technical story to do that. I challenged them to create a story in terms of the customer's interests.

Rather quickly they came up with this conversation: 

"Ms Customer, when your people come to work in the morning, would you like them to press a button and wait two hours for the data to show up, or would you like it to be ready when they come in?" 

"You tiny fools! I pay those people good money! I want them to start work right away!"

"We thought so. Please write a story saying 'Have data ready first thing in the morning'. Thanks!"

Lesson: if it needs to be done, there is a user-centric reason why.

Larger lesson: anything can be done in short Sprints delivering software that the user can see the value in.

Ron Jeffries
www.XProgramming.com
Impossible is not a fact. It is an opinion.  -- Muhammad Ali



__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Michael James | 15 Jul 2012 07:02
Picon

Re: How to split a story that doesn't have customer value when split

I enjoyed reading this. 

--mj


On Jul 14, 2012, at 4:59 PM, RonJeffries <ronjeffries <at> acm.org> wrote:

 


On Jul 8, 2012, at 5:20 PM, Cass Dalton wrote:

One of the difficulties of the systems my company builds is that they are real time systems with multiple software and hardware components.  

OK ...

Lets say that you have a system that has to interact with an existing system.  It has to intercept events that are passing through the system.  Some events are notifications, some events are compact data streams.  Each data stream has a preceding notification.  

Yes. Doubtless each can be seen as some string of bytes that can be told from the others, according to some protocol. This makes me foresee a split along different events, doing one at a time.

There are some notifications/data streams that we want to process, some that we don't.  

Yes. So an early story might be to show the ability to partition them into the ones we want and the ones we do not want.

There are post-processing plug-ins.  Each plug-in is interested in a different set of notifications.  These plug-ins, the management of the data and messages, and everything new aside from a minimal amount of code have to live on one or more separate machines (a non-negotiable political customer constraint).  

OK. Seems clear that each plug-in is a separate story, quite possibly even a separate product. They do not all have the same value, almost certainly, and should probably be done with the high-value ones first. So here again,we see some things to split out.

The first plug-in to be used requires a huge amount of signal processing to get any information out of the data stream.  For example, lets assume that we have to parse an HTML stream from only the voltages as seen by the network interface card.  But we don't have a NIC, we don't have access to any of the existing ethernet driver code, TCP/IP network stack, HTTP libraries, etc.  We have to write all that from scratch.

Congratulations for finding hardware for which there is no network stack. These, too, seem like separate projects, not all part of one giant story.

The HTML stream, as someone already mentioned, sounds a lot like a pre-made design decision. Perhaps it is part of the contract. If so, then there is probably some agreed or predefined p rotocol. At a guess it might be better to think of this as XML rather than HTMl. Either way, one does not need an HTTP library to produce HTML. print "<head></head><body></body>" might be my first cut at the library. I would let the library emerge.

As for the voltages from the NIC, the hardware will surely have instructions for reading those bits, deciding what voltages to request, and so on. This, too, will be a small protocol that is readily partitioned. Last time I did something like that, I wrote a small assembler routine that set the right values on the pins, read the resulting outputs. Had a timing loop in it, if I recall. Perhaps a more modern computer would raise an interrupt when the values were ready. Either way, a day's work to read the first value. After that, one just grows more and more capability.

It begins to become clear that there are lots of separable project bits which may want to run asynchronously in time, maybe even on different hardware / software platforms. I'd negotiate simple starting protocols between separate teams, if I had them. Each team would mock one side of the interface, with tests, so that when the other team had some of the interface "ready" there would be tests available for them to work through. Regular meetings would update the protocol and tests. The teams would work in lock step or async as seemed best.

The user need is that they want to automatically parse the HTML from these data streams.  To get this done, we have to interface to the existing system, build something that will intelligently route the data to the right post-processor, something that will make sure that the right processor is installed (we're always striving for deliverable code at the end of each sprint), and we need the processor.  

You have just described a few more separable bits right here. For these, too, we can provide mock objects with tests to manage the interfaces. We can, for example, create a mocked-up HTML stream a nd feed it to the processor that parses it. That will show the extent to which the parsing works. Naturally, since the message in HTML has various parts, the parsing project can work on them one after another.

Similarly, we can mock the "intelligent routing", essentially hard-coding the processor choice. If I understood your description, the processor choice is embedded in the HTML? Anyway it will be somewhere in some protocol. Wherever it is, we identify a second message that needs to go to a different processor. We feed that with two streams and test whether it selects the right one. Now we have a slightly more mature "intelligent routing". Then we pick another protocol to select on.

I know that I have already assumed some of the system design in this description, but it is for the purpose of describing the complexity of the system.  Lets just assume that this system design is what the team decided was the best solution.  Even by taking liberties like hardcoding the post-processor to use and things like that, it will still take at least three sprints to come close to anything that they customer will see as value.

I don't think that's the case. If your team is any good, I'd wager we could produce something that would show the customer real progress in a single Sprint. Would they ship it? No, certainly not. Would they use it? Not yet. But they would see a tiny, embryonic, running system, where we could point to the tiny embryonic elements that we had built, and to the holes were the ones were that we had skipped over entirely. 

This system might have a few component stories, perhaps along these lines:
  • Read values from Register A of the NIC
  • Detect Protocol A and dispatch to Processor A
  • In Processor A, read simple HTML message and correctly identify it
  • ... and so on

Whatever work needs to be done is in service of the customer need. Whatever work is going to be done, we can and should make parts of it work every day, not just ever week or month. Therefore, we choose and define the work so that its value to the customer is understandable by the customer.

This reminds me of a story. A team I was working with had built a big system that processed mainframe data on local processors in the user site. One of the things that had to be done was to FTP the data from the mainframe over to the locals, in the middle of the night. They asked me if they could just write a technical story to do that. I challenged them to create a story in terms of the customer's interests.

Rather quickly they came up with this conversation: 

"Ms Customer, when your people come to work in the morning, would you lik e them to press a button and wait two hours for the data to show up, or would you like it to be ready when they come in?" 

"You tiny fools! I pay those people good money! I want them to start work right away!"

"We thought so. Please write a story saying 'Have data ready first thing in the morning'. Thanks!"

Lesson: if it needs to be done, there is a user-centric reason why.

Larger lesson: anything can be done in short Sprints delivering software that the user can see the value in.

Ron Jeffries
www.XProgramming.com
Impossible is not a fact. It is an opinion.  -- Muhammad Ali



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
RonJeffries | 15 Jul 2012 13:23
Picon
Favicon
Gravatar

Re: How to split a story that doesn't have customer value when split

mj,

On Jul 15, 2012, at 1:02 AM, Michael James wrote:

I enjoyed reading this. 

I always figure if you can't be useful you should at least b e entertaining ... :)

Ron Jeffries
www.XProgramming.com
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Charles Bradley Scrum Coach CSP CSM PSM I | 15 Jul 2012 08:28

Re: How to split a story that doesn't have customer value when split

Cass, my first question is this:

Who gets value out of this functionality?  What value do they get?  I'd need to know more about that before I could suggest splits because I'd like the split story to deliver value if at all possible. Please try to use lay terms as much as possible in your description.

Charles

Sent from my iPhone

On Jul 14, 2012, at 5:59 PM, RonJeffries <ronjeffries <at> acm.org> wrote:


On Jul 8, 2012, at 5:20 PM, Cass Dalton wrote:

One of the difficulties of the systems my company builds is that they are real time systems with multiple software and hardware componen ts.  

OK ...

Lets say that you have a system that has to interact with an existing system.  It has to intercept events that are passing through the system.  Some events are notifications, some events are compact data streams.  Each data stream has a preceding notification.  

Yes. Doubtless each can be seen as some string of bytes that can be told from the others, according to some protocol. This makes me foresee a split along different events, doing one at a time.

There are some notifications/data streams that we want to process, some that we don't.  

Yes. So an early story might be to show the ability to partition them into the ones we want and the ones we do not want.

There are post-processing plug-ins.  Each plug-in is interested in a different set of notifications.  These plug-ins, the management of the data and messages, and everything new aside from a minimal amount of code have to live on one or more separate machines (a non-negotiable political customer constraint).  

OK. Seems clear that each plug-in is a separate story, quite possibly even a separate product. They do not all have the same value, almost certainly, and should probably be done with the high-value ones first. So here again,we see some things to split out.iv>
The first plug-in to be used requires a huge amount of signal processing to get any information out of the data stream.  For example, lets assume that we have to parse an HTML stream from only the voltages as seen by the netwo rk interface card.  But we don't have a NIC, we don't have access to any of the existing ethernet driver code, TCP/IP network stack, HTTP libraries, etc.  We have to write all that from scratch.

Congratulations for finding hardware for which there is no network stack. These, too, seem like separate projects, not all part of one giant story.

The HTML stream, as someone already mentioned, sounds a lot like a pre-made design decision. Perhaps it is part of the contract. If so, then there is probably some agreed or predefined protocol. At a guess it might be better to think of this as XML rather than HTMl. Either way, one does not need an HTTP library to produce HTML. print "<head></head><body></b ody>" might be my first cut at the library. I would let the library emerge.

As for the voltages from the NIC, the hardware will surely have instructions for reading those bits, deciding what voltages to request, and so on. This, too, will be a small protocol that is readily partitioned. Last time I did something like that, I wrote a small assembler routine that set the right values on the pins, read the resulting outputs. Had a timing loop in it, if I recall. Perhaps a more modern computer would raise an interrupt when the values were ready. Either way, a day's work to read the first value. After that, one just grows more and more capability.

It begins to become clear that there are lots of separable project bits which may want to run asynchronously in time, maybe even on different hardware / software platforms. I'd negotiate simple starting protocols between separate teams, if I had them. Each team would mock one side of the interface, with tests, so that when the other team had some of the interface "ready" there would be tests available for them to work through. Regular meetings would update the protocol and tests. The teams would work in lock step or async as seemed best.

The user need is that they want to automatically parse the HTML from these data streams.  To get this done, we have to interface to the existing system, build something that will intelligently route the data to the right post-processor, something that will make sure that the right processor is installed (we're always striving for deliverable code at the end of each sprint), and we need the processor.  

You have just described a few more separable bits right here. For these, too, we can provide mock objects w ith tests to manage the interfaces. We can, for example, create a mocked-up HTML stream and feed it to the processor that parses it. That will show the extent to which the parsing works. Naturally, since the message in HTML has various parts, the parsing project can work on them one after another.

Similarly, we can mock the "intelligent routing", essentially hard-coding the processor choice. If I understood your description, the processor choice is embedded in the HTML? Anyway it will be somewhere in some protocol. Wherever it is, we identify a second message that needs to go to a different processor. We feed that with two streams and test whether it selects the right one. Now we have a slightly more mature "intelligent routing". Then we pick another protocol to select on.

I know that I have already assumed some of the system design in this description, but it is for the purpose of describing the complexity of the system.  Lets just assume that this system design is what the team de cided was the best solution.  Even by taking liberties like hardcoding the post-processor to use and things like that, it will still take at least three sprints to come close to anything that they customer will see as value.

I don't think that's the case. If your team is any good, I'd wager we could produce something that would show the customer real progress in a single Sprint. Would they ship it? No, certainly not. Would they use it? Not yet. But they would see a tiny, embryonic, running system, where we could point to the tiny embryonic elements that we had built, and to the holes were the ones were that we had skipped over entirely. 

This system might have a few component stories, perhaps along these lines :
  • Read values from Register A of the NIC
  • Detect Protocol A and dispatch to Processor A
  • In Processor A, read simple HTML message and correctly identify it
  • ... and so on

Whatever work needs to be done is in service of the customer need. Whatever work is going to be done, we can and should make parts of it work every day, not just ever week or month. Therefore, we choose and define the work so that its value to the customer is understandable by the customer.

This reminds me of a story. A team I was working with had built a big system that processed mainframe data on local processors in the user site. One of the things that had to be done was to FTP the data from the mainframe over to the locals, in the middle of the night. They asked me if they could just write a technical story to do that. I challenged them to create a story in terms of the customer's interests.

Rather quickly they came up with this conversation: 

"Ms Customer, when your people come to work in the morning, would you like them to press a button and wait two hours for the data to show up, or would you like it to be ready when they come in?" 

"You tiny fools! I pay those people good money! I want them to start work right away!"

"We thought so. Please write a story saying 'Have data ready first thing in the morning'. Thanks!"

Lesson: if it needs to be done, there is a user-centric reason why.

Larger lesson: anything can be done in short Sprints delivering software that the user can see the value in.

Ron Jeffries
www.XProgramming.com
Impossible is not a fact. It is an opinion.  -- Muhammad Ali



__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
George Dinwiddie | 17 Jul 2012 03:04
Favicon

Re: How to split a story that doesn't have customer value when split

Cass,

I've been waiting for time to formulate a useful reply to this.

On 7/8/12 5:20 PM, Cass Dalton wrote:
> One of the difficulties of the systems my company builds is that they
> are real time systems with multiple software and hardware components.

Cool! Are you aware of http://groups.yahoo.com/group/AgileEmbedded/ ?

> Lets say that you have a system that has to interact with an existing
> system.  It has to intercept events that are passing through the system.
>   Some events are notifications, some events are compact data streams.
>   Each data stream has a preceding notification.

Are these one to one? Or may there be multiple notifications before a 
data stream? Or notifications that have no data stream?

>  There are some
> notifications/data streams that we want to process, some that we don't.
>   There are post-processing plug-ins.  Each plug-in is interested in a
> different set of notifications.

I presume the "we" in that first sentence is "a particular plug-in." Is 
that correct?

> These plug-ins, the management of the
> data and messages, and everything new aside from a minimal amount of
> code have to live on one or more separate machines (a non-negotiable
> political customer constraint).  The first plug-in to be used requires a
> huge amount of signal processing to get any information out of the data
> stream.

What about the notification? What's required to understand it?

> For example, lets assume that we have to parse an HTML stream
> from only the voltages as seen by the network interface card.  But we
> don't have a NIC, we don't have access to any of the existing ethernet
> driver code, TCP/IP network stack, HTTP libraries, etc.  We have to
> write all that from scratch.

Why from scratch? Once you convert the voltages to ones and zeros, you 
should be able to use an off-the-shelf network stack.

> The user need is that they want to automatically parse the HTML from
> these data streams.

That sounds like a proposed solution, rather than a need. Surely they 
have some use for the parsed HTML.

> To get this done, we have to interface to the
> existing system, build something that will intelligently route the data
> to the right post-processor, something that will make sure that the
> right processor is installed (we're always striving for deliverable code
> at the end of each sprint), and we need the processor.

It sounds like the guts of the system is two-fold:
  1. to decide which plugin needs to process the data, &
  2. to process the data in some unspecified way.

> I know that I
> have already assumed some of the system design in this description, but
> it is for the purpose of describing the complexity of the system.  Lets
> just assume that this system design is what the team decided was the
> best solution.  Even by taking liberties like hardcoding the
> post-processor to use and things like that, it will still take at least
> three sprints to come close to anything that they customer will see as
> value.

Is it the processing of the data (which appears to be the real reason 
for the system) the thing you think will take 3 weeks? If so, we'll 
certainly need to know more about what sort of processing you're doing.

If it's the network interface that's slowing you down, I'd skip that at 
first. Prove the processing works to the customer's satisfaction. 
There's huge value in that.

I'd start with using some off-the-shelf hardware and software to give 
the network interface, and develop the logical heart of the matter, 
first. I'd likely start with a simpler process, just to prove out the 
decision-making. Or I might start out with hard-coding the decision and 
starting with the processor, as you suggest.

Either way, I'm sure there are more splits that can be done.

Once those two things are working, at least rudimentarily, then I would 
start working backwards to replace the hardware with software, assuming 
that's a requirement.

> But in my example, that's akin to taking a string of
> the ethernet voltages and manually translating them to IP packets,
> manually translating the string of IP packets to a TCP connection, etc
> on to the HTML stream.  There's some customer value in that you are
> understanding the customer's need, but there's still a lot of work to do
> to build the actual system.

Yes, I don't know why your solution is specified to do everything from 
scratch. Of course, the good thing is that some of these are well-known 
problems (well-known in the industry, if not to particular people) and 
can also be done in parallel if you've got enough people available.

If you don't have enough people then, well, lots of work means it takes 
lots of time. There's still value in seeing the novel parts of the 
system work early, and leaving the well-known problems to later.

I hope I've understood you well enough.

  - George

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
Charles Bradley - Scrum Coach CSP CSM PSM I | 17 Jul 2012 04:05

Re: How to split a story that doesn't have customer value when split

Like MJ, I enjoyed Ron's and George's responses.  Even by email, you guys are such great collaborators.  I'm sure you've helped more than just the OP.
 
-------
Charles Bradley
http://www.ScrumCrazy.com


From: George Dinwiddie <lists <at> idiacomputing.com>
To: scrumdevelopment <at> yahoogroups.com
Sent: Monday, July 16, 2012 7:04 PM
Subject: Re: [scrumdevelopment] How to split a story that doesn't have customer value when split

Cass,

I've been waiting for time to formulate a useful reply to this.

On 7/8/12 5:20 PM, Cass Dalton wrote:
> One of the difficulties of the systems my company builds is that they
> are real time systems with multiple software and hardware components.

Cool! Are you aware of http://groups.yahoo.com/group/AgileEmbedded/ ?

> Lets say that you have a system that has to interact with an existing
> system.  It has to intercept events that are passing through the system.
>  Some events are notifications, some events are compact data streams.
>  Each data stream has a preceding notification.

Are these one to one? Or may there be multiple notifications before a
data stream? Or notifications that have no data stream?

>  There are some
> notifications/data streams that we want to process, some that we don't.
>  There are post-processing plug-ins.  Each plug-in is interested in a
> different set of no tifications.

I presume the "we" in that first sentence is "a particular plug-in." Is
that correct?

> These plug-ins, the management of the
> data and messages, and everything new aside from a minimal amount of
> code have to live on one or more separate machines (a non-negotiable
> political customer constraint).  The first plug-in to be used requires a
> huge amount of signal processing to get any information out of the data
> stream.

What about the notification? What's required to understand it?

> For example, lets assume that we have to parse an HTML stream
> from only the voltages as seen by the network interface card.  But we
> don't have a NIC, we don't have access to any of the existing ethernet
> driver code, TCP/IP network stack, HTTP libraries, etc.  We have to
> write all that from scratch.

Why from scratch? Once you convert the v oltages to ones and zeros, you
should be able to use an off-the-shelf network stack.

> The user need is that they want to automatically parse the HTML from
> these data streams.

That sounds like a proposed solution, rather than a need. Surely they
have some use for the parsed HTML.

> To get this done, we have to interface to the
> existing system, build something that will intelligently route the data
> to the right post-processor, something that will make sure that the
> right processor is installed (we're always striving for deliverable code
> at the end of each sprint), and we need the processor.

It sounds like the guts of the system is two-fold:
  1. to decide which plugin needs to process the data, &
  2. to process the data in some unspecified way.

> I know that I
> have already assumed some of the system design in this description, but> it is for the purpose of describing the complexity of the system.  Lets
> just assume that this system design is what the team decided was the
> best solution.  Even by taking liberties like hardcoding the
> post-processor to use and things like that, it will still take at least
> three sprints to come close to anything that they customer will see as
> value.

Is it the processing of the data (which appears to be the real reason
for the system) the thing you think will take 3 weeks? If so, we'll
certainly need to know more about what sort of processing you're doing.

If it's the network interface that's slowing you down, I'd skip that at
first. Prove the processing works to the customer's satisfaction.
There's huge value in that.

I'd start with using some off-the-shelf hardware and software to give
the network interface, and develop the logical heart of the matter,
first. I'd likely start with a simpler process, just to prove out the
decision-making. Or I might start out with hard-coding the decision and
starting with the processor, as you suggest.

Either way, I'm sure there are more splits that can be done.

Once those two things are working, at least rudimentarily, then I would
start working backwards to replace the hardware with software, assuming
that's a requirement.

> But in my example, that's akin to taking a string of
> the ethernet voltages and manually translating them to IP packets,
> manually translating the string of IP packets to a TCP connection, etc
> on to the HTML stream.  There's some customer value in that you are
> understanding the customer's need, but there's still a lot of work to do
> to build the actual system.

Yes, I don't know why your solution is specified to do everything from
scratch. Of course, the good thing is that some of these are well-known
problems (well-known in the industry, if not to particular people) and
can also be done in parallel if you've got enough people available.

If you don't have enough people then, well, lots of work means it takes
lots of time. There's still value in seeing the novel parts of the
system work early, and leaving the well-known problems to later.

I hope I've understood you well enough.

  - George

--
  ----------------------------------------------------------------------
  * George Dinwiddie *                      http://blog.gdinwiddie.com
  Software Development                    http://www.idiacomputing.com
&nb sp; Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------





------------------------------------

To Post a message, send it to:  scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumd evelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/





__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Cass Dalton | 17 Jul 2012 13:27
Picon

Re: How to split a story that doesn't have customer value when split

Cool! Are you aware of http://groups.yahoo.com/group/AgileEmbedded/ ?

I was not, but I will take a look
 
> Lets say that you have a system that has to interact with an existing
> system.  It has to intercept events that are passing through the system.
>   Some events are notifications, some events are compact data streams.
>   Each data stream has a preceding notification.

Are these one to one? Or may there be multiple notifications before a
data stream? Or notifications that have no data stream?


Not sure it's important to the point of the story, but lets say they are one to one.
 
>  There are some
> notifications/data streams that we want to process, some that we don't.
>   There are post-processing plug-ins.  Each plug-in is interested in a
> different set of notifications.

I presume the "we" in that first sentence is "a particular plug-in." Is
that correct?


Effectively, yes; we means a plug in.  Every plug in you add needs to add a new notification parameter to look for.
 
> These plug-ins, the management of the
> data and messages, and everything new aside from a minimal amount of
> code have to live on one or more separate machines (a non-negotiable
> political customer constraint).  The first plug-in to be used requires a
> huge amount of signal processing to get any information out of the data
> stream.

What about the notification? What's required to understand it?

Pretend it's key value pairs.
 

> For example, lets assume that we have to parse an HTML stream
> from only the voltages as seen by the network interface card.  But we
> don't have a NIC, we don't have access to any of the existing ethernet
> driver code, TCP/IP network stack, HTTP libraries, etc.  We have to
> write all that from scratch.

Why from scratch? Once you convert the voltages to ones and zeros, you
should be able to use an off-the-shelf network stack.

The point of this analogy is to portray the complexity of a general task that we have to perform.  I can't describe any of the actual tasks we have to do for various reasons, so I came up with the best example I could that I through members of the group could relate to without giving too much away.  It's just an analogy.  We would never rewrite a common network stack from scratch.
 

> The user need is that they want to automatically parse the HTML from
> these data streams.

That sounds like a proposed solution, rather than a need. Surely they
have some use for the parsed HTML.

Yes it is, and I acknowledged that later in my story.  It's for the sake of portraying the complexity in a language that everyone would understand.  The lawnmower analogy didn't go over well, so I had to come up with a contrived example to get my point across.  The actual details are not important because they are made up.
 

> To get this done, we have to interface to the
> existing system, build something that will intelligently route the data
> to the right post-processor, something that will make sure that the
> right processor is installed (we're always striving for deliverable code
> at the end of each sprint), and we need the processor.

It sounds like the guts of the system is two-fold:
  1. to decide which plugin needs to process the data, &
  2. to process the data in some unspecified way.

> I know that I
> have already assumed some of the system design in this description, but
> it is for the purpose of describing the complexity of the system.  Lets
> just assume that this system design is what the team decided was the
> best solution.  Even by taking liberties like hardcoding the
> post-processor to use and things like that, it will still take at least
> three sprints to come close to anything that they customer will see as
> value.

Is it the processing of the data (which appears to be the real reason
for the system) the thing you think will take 3 weeks? If so, we'll
certainly need to know more about what sort of processing you're doing.

If it's the network interface that's slowing you down, I'd skip that at
first. Prove the processing works to the customer's satisfaction.
There's huge value in that.

The processing IS the network stack.  The data stream is basically an HTTP stream but as captured on the actual wire and the processing has to do that conversion (remember, contrived example just to describe the complexity of the problem).

 

I'd start with using some off-the-shelf hardware and software to give
the network interface, and develop the logical heart of the matter,
first. I'd likely start with a simpler process, just to prove out the
decision-making. Or I might start out with hard-coding the decision and
starting with the processor, as you suggest.

The point is, I CANT use off the shelf hardware and software.  Imagine that there are two completely separate network stacks:  one that I use to network my actual servers together, and one that I have to write from scratch (contrived example... network stack just for describing complexity...  don't have any existing HW/SW to pull from which is what drives the complexity... etc)
 

Either way, I'm sure there are more splits that can be done.

Once those two things are working, at least rudimentarily, then I would
start working backwards to replace the hardware with software, assuming
that's a requirement.

> But in my example, that's akin to taking a string of
> the ethernet voltages and manually translating them to IP packets,
> manually translating the string of IP packets to a TCP connection, etc
> on to the HTML stream.  There's some customer value in that you are
> understanding the customer's need, but there's still a lot of work to do
> to build the actual system.

Yes, I don't know why your solution is specified to do everything from
scratch. Of course, the good thing is that some of these are well-known
problems (well-known in the industry, if not to particular people) and
can also be done in parallel if you've got enough people available.

Yes, I picked a contrived well known problem that was obviously silly given the wealth of IP available to perform the processing in order to easily describe how complicated the processing was to get even the smallest amount of value.  If all the customer cares about is the HTTP stream, then they will find it hard to see value in decoding the voltages, or converting those to IP packets, etc...

 

If you don't have enough people then, well, lots of work means it takes
lots of time. There's still value in seeing the novel parts of the
system work early, and leaving the well-known problems to later.


Yes, and my question relates to the best practice of not splitting stories on architectural or other artificial lines.  We're supposed to split the story with thin slices all the way through the system.  But with 3 sprints (not 3 weeks, but that's semantics) just to get some basic functionality that the customer would understand, how do you write the story to be worked in sprint 1?  I want to start off with a thread all the way through the system, but what if you can't?  If it takes more than 1 sprint to get a thread through, how do you choose where to split?  Is splitting on architectural lines OK if that's all you have? (seems like everyone advises against that, but I can't figure out another way).



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Otis Bricker | 17 Jul 2012 05:44
Picon

Re: How to split a story that doesn't have customer value when split

Reading the other responses, I started thinking of another example based on today's date.

When the US decided to send a man to the Moon, there was no single story for the Saturn V and Lunar Lander. That Single story was broken up into various smaller stories and executed. Some in parallel. Each stage had value and shaped the future stories by proving concepts and providing more information for making the later decisions.

Atlas, Mercury and Gemini ' releases' were each, in turn, broken into stories. This all lead to the final 'deployment' between July 16 and July 24 1969.

Not an exact match but it seems close.

Otis

On 7/8/2012 5:20 PM, Cass Dalton wrote:
Laurent,
I agree that we constantly want to ask "why" especially when our customers seem to already have a solution in mind.  I attempt to do this at work constantly.  I have redirected customers to better solutions when they already had a solution in mind.  I may have written my initial user story poorly, but my intention was to write a user story that truly represented exactly what the user needed so that we could focus on my problem.  The user story was not the important part of the analogy for me.  It was to be assumed that there was some user need that couldn't easily be implemented in a single implementation.  As someone with only a traditional waterfall background, my initial reaction usually would have been to write a story for the wheels, a story for the engine, a story for the chassis, etc.

The suggestion from Otis is interesting in that it breaks up what I thought was an atomic need into incremental needs.  I have done that sort of thing at work without really realizing that that was what I was doing.  One problem is that the suggestion results in a complete rewrite of the system each time.  Or alternatively, a set of increasingly more complex prototypes.

Ron,
OK, so let me try to make a software analogy.

One of the difficulties of the systems my company builds is that they are real time systems with multiple software and hardware components.  
Lets say that you have a system that has to interact with an existing system.  It has to intercept events that are passing through the system.  Some events are notifications, some events are compact data streams.  Each data stream has a preceding notification.  There are some notifications/data streams that we want to process, some that we don't.  There are post-processing plug-ins.  Each plug-in is interested in a different set of notifications.  These plug-ins, the management of the data and messages, and everything new aside from a minimal amount of code have to live on one or more separate machines (a non-negotiable political customer constraint).  The first plug-in to be used requires a huge amount of signal processing to get any information out of the data stream.  For example, lets assume that we have to parse an HTML stream from only the voltages as seen by the network interface card.  But we don't have a NIC, we don't have access to any of the existing ethernet driver code, TCP/IP network stack, HTTP libraries, etc.  We have to write all that from scratch.

The user need is that they want to automatically parse the HTML from these data streams.  To get this done, we have to interface to the existing system, build something that will intelligently route the data to the right post-processor, something that will make sure that the right processor is installed (we're always striving for deliverable code at the end of each sprint), and we need the processor.  I know that I have already assumed some of the system design in this description, but it is for the purpose of describing the complexity of the system.  Lets just assume that this system design is what the team decided was the best solution.  Even by taking liberties like hardcoding the post-processor to use and things like that, it will still take at least three sprints to come close to anything that they customer will see as value.

Relating back to the scythe example, we have some something akin to an offline version of the post-processor and demonstrating that to the customer.  But it still takes multiple sprints just to build that, and that solution only goes so far:  If you build them a scythe as a stepping stone to a lawn mower, what value have you gained?  Is the scythe a technological step towards a lawn mower?  If so, then you have value.  If not, then you have built something that you have to throw away.  That's OK if you learned something from the scythe about the customer's needs.  But in my example, that's akin to taking a string of the ethernet voltages and manually translating them to IP packets, manually translating the string of IP packets to a TCP connection, etc on to the HTML stream.  There's some customer value in that you are understanding the customer's need, but there's still a lot of work to do to build the actual system.



On Sun, Jul 8, 2012 at 4:32 PM, George Dinwiddie <lists <at> idiacomputing.com> wrote:
 

Laurent,



On 7/8/12 3:53 PM, Laurent Bossavit wrote:
> Hi Ron,
>
>> Are you building lawnmowers? In that case I don't know. If you
>> happen to be building software, please tell us a real software
>> story. We might be able to help with that.
>
> Actually I kind of disagree with you there - the mower example is
> sort of interesting to think about. Got *me* thinking, anyway, for
> which I'm grateful to Cass. (Hi Cass! Thanks!)

That may be, but I've found that mechanical metaphors generally aren't
very useful to people learning how to split user stories. Software is
much more malleable than most construction materials. And software is
more like the plans or models of the final product--a friend who has
taught parametric mechanical modeling tells me that working from that
viewpoint is a new thing to most mechanical designers, too.

So, my initial reaction is the same as Ron's. If he hadn't responded as
he did, I would have asked a very similar question.

- George

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------






__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
RonJeffries | 8 Jul 2012 22:31
Picon
Favicon
Gravatar

Re: How to split a story that doesn't have customer value when split

Hi Laurent,

On Jul 8, 2012, at 3:53 PM, Laurent Bossavit wrote:

Yet, on considered reflection, this seems a more useful path to me than starting with "Assume we have requirements such that we just can't build in small slices; then how do we build in small slices?" If that's the problem statement, *something's* got to give - either the small slices, or the requirements. That's the nub of the question as I see it.

Well, perhaps. However, I'm still not expert in lawnmowers, and if this is a software product we're really talking about, I've never seen one that couldn't be built in small slices, so I'm hoping either to be more useful there, or educated. :)

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Adam Sroka | 8 Jul 2012 23:54
Picon
Gravatar

Re: How to split a story that doesn't have customer value when split

They are mostly software nowadays, and I've personally consulted both John Deere and Caterpillar about their use of Agile methods in the development of the embedded portions.
Building the actual tractors is still mostly done by machines and engineers but there's a lot of software in the things today. That said, the construction of the whole machine is a horrible metaphor for the construction of the embedded software, and that conflation is something such organizations struggle with as well.

On Jul 8, 2012 1:32 PM, "RonJeffries" <ronjeffries <at> acm.org> wrote:
 

Hi Laurent,


On Jul 8, 2012, at 3:53 PM, Laurent Bossavit wrote:

Yet, on considered reflection, this seems a more useful path to me than starting with "Assume we have requirements such that we just can't build in small slices; then how do we build in small slices?" If that's the problem statement, *something's* got to give - either the small slices, or the requirements. That's the nub of the question as I see it.

Well, perhaps. However, I'm still not expert in lawnmowers, and if this is a software product we're really talking about, I've never seen one that couldn't be built in small slices, so I'm hoping either to be more useful there, or educated. :)

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide



__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Angel Java Lopez | 9 Jul 2012 00:04
Picon

Re: How to split a story that doesn't have customer value when split

Curiously, for me (English is not my mother tongue, and in a country where riding mower are for "big" places, not usually for a homeowner)  "as a homeowner, I want to mow my lawn without pushing a mower" doesn't imply "you asked for a riding mower". The first time I read the sentence, I think "you need a boy that push the mower" ;-) I don't sure "I want to mow..." means "I want to mow (myself)..."

On Sun, Jul 8, 2012 at 6:54 PM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
 

They are mostly software nowadays, and I've personally consulted both John Deere and Caterpillar about their use of Agile methods in the development of the embedded portions.
Building the actual tractors is still mostly done by machines and engineers but there's a lot of software in the things today. That said, the construction of the whole machine is a horrible metaphor for the construction of the embedded software, and that conflation is something such organizations struggle with as well.

On Jul 8, 2012 1:32 PM, "RonJeffries" <ronjeffries <at> acm.org> wrote:
 

Hi Laurent,


On Jul 8, 2012, at 3:53 PM, Laurent Bossavit wrote:

Yet, on considered reflection, this seems a more useful path to me than starting with "Assume we have requirements such that we just can't build in small slices; then how do we build in small slices?" If that's the problem statement, *something's* got to give - either the small slices, or the requirements. That's the nub of the question as I see it.

Well, perhaps. However, I'm still not expert in lawnmowers, and if this is a software product we're really talking about, I've never seen one that couldn't be built in small slices, so I'm hoping either to be more useful there, or educated. :)

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide




__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Cass Dalton | 8 Jul 2012 19:24
Picon

Re: How to split a story that doesn't have customer value when split

Im sorry that the analogy was lost on you.  I would love to tell you a real story.  Do you have a security clearance?

The basic question is not that complicated.  You have a single feature point that needs 20 man weeks of work behind it to provide real value to a user.  You have a team of 3 developers.

I can't imagine that no one in the agile community has not come across the situation where you are building a complicated system from scratch and it takes a number of sprints before the customer sees any visible value.  That's what the lawnmower analogy was designed to signify.  I did not expect people to get stuck in the technicalities of the analogy.

On Jul 8, 2012 11:57 AM, "RonJeffries" <ronjeffries <at> acm.org> wrote:
 

Hello, Cass,


On Jul 3, 2012, at 9:17 PM, Cass Dalton wrote:

The projects I work on are like this.  There is a single primary feature that requires a lot of work (i.e. multiple sprints) just to get a system that provides minimal customer value.  Once you have that, many of the follow on features start to roll off in good user stories.

So how do you split up these types of epics?

Are you building lawnmowers? In that case I don't know. If you happen to be building software, please tell us a real software story. We might be able to help with that.

Thanks,

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell



__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Mark Levison | 13 Jul 2012 19:57
Gravatar

Re: How to split a story that doesn't have customer value when split



On Sun, Jul 8, 2012 at 1:24 PM, Cass Dalton <cassdalton73 <at> gmail.com> wrote:
 

Im sorry that the analogy was lost on you.  I would love to tell you a real story.  Do you have a security clearance?

The basic question is not that complicated.  You have a single feature point that needs 20 man weeks of work behind it to provide real value to a user.  You have a team of 3 developers.

I can't imagine that no one in the agile community has not come across the situation where you are building a complicated system from scratch and it takes a number of sprints before the customer sees any visible value.  That's what the lawnmower analogy was designed to signify.  I did not expect people to get stuck in the technicalities of the analogy.


Cass - I hear this comment: "I can't imagine that no one in the agile community has not come across the situation where you are building a complicated system from scratch and it takes a number of sprints before the customer sees any visible value" on a regular basis. While I agree that no everything can be split, far more than most people think can be split.

It would really help if you gave us some idea of a real piece of software that we could discuss to help frame the problem. 

Some tools I use to start splitting:
- consider the use of fakes/mocks/stubs - fake email server to send mail to; fake database of reviews when building the next amazon; ....- anything that allows you to decouple the software from aspect of the system that we don't want to build yet.
- command line vs gui - sometimes we can get the command line version of something right on the first try before adding the complexity of GUI elements. If i were employed building the next git I would use this a lot.
....

There are heaps of articles out there on Story Splitting:

Please read several and tell us why none of these splits would work for you.

Cheers
Mark

 
On Jul 8, 2012 11:57 AM, "RonJeffries" <ronjeffries <at> acm.org> wrote:
 

Hello, Cass,


On Jul 3, 2012, at 9:17 PM, Cass Dalton wrote:

The projects I work on are like this.  There is a single primary feature that requires a lot of work (i.e. multiple sprints) just to get a system that provides minimal customer value.  Once you have that, many of the follow on features start to roll off in good user stories.

So how do you split up these types of epics?

Are you building lawnmowers? In that case I don't know. If you happen to be building software, please tell us a real software story. We might be able to help with that.

Thanks,

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell




__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Michael James | 13 Jul 2012 21:26
Picon

Re: How to split a story that doesn't have customer value when split


Dude, you forgot mine!


--mj
http://ScrumTrainingSeries.com  <-- also contains an elearning module on the Backlog Refinement Meeting



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Mark Levison | 13 Jul 2012 21:30
Gravatar

Re: How to split a story that doesn't have customer value when split



On Fri, Jul 13, 2012 at 3:26 PM, Michael James <mj4scrum <at> gmail.com> wrote:

It was personal and you know it :-) Sorry. Google failed me.

Cheers
Mark 


--mj
http://ScrumTrainingSeries.com  <-- also contains an elearning module on the Backlog Refinement Meeting




__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
George Dinwiddie | 13 Jul 2012 21:36
Favicon

Re: How to split a story that doesn't have customer value when split

Adding onto what Mark said,

On 7/13/12 1:57 PM, Mark Levison wrote:
> Cass - I hear this comment: "I can't imagine that no one in the agile
> community has not come across the situation where you are building a
> complicated system from scratch and it takes a number of sprints before
> the customer sees any visible value" on a regular basis. While I agree
> that no everything can be split, far more than most people think can be
> split.
>
> It would really help if you gave us some idea of a real piece of
> software that we could discuss to help frame the problem.
>
> Some tools I use to start splitting:
> - consider the use of fakes/mocks/stubs - fake email server to send mail
> to; fake database of reviews when building the next amazon; ....-
> anything that allows you to decouple the software from aspect of the
> system that we don't want to build yet.
> - command line vs gui - sometimes we can get the command line version of
> something right on the first try before adding the complexity of GUI
> elements. If i were employed building the next git I would use this a lot.
> ....
>
> There are heaps of articles out there on Story Splitting:
> http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
>
> http://agilepainrelief.com/notesfromatooluser/2010/12/more-notes-on-story-splitting.html
>
> http://www.agileforall.com/2009/12/10/new-to-agile-learn-how-to-split-stories/
>
> http://lassekoskela.com/thoughts/7/ways-to-split-user-stories/
> http://xp123.com/articles/twenty-ways-to-split-stories/
>
> Please read several and tell us why none of these splits would work for you.

You can also come up with the essential examples that represent a story 
and then split the story by taking small groups of those examples. I 
mention that and point to a few more articles on splitting stories at 
http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/

  - George

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
SilvanaWasitova | 13 Jul 2012 20:05
Picon
Favicon
Gravatar

Re: How to split a story that doesn't have customer value when split

Cass,

It's not that your analogy is lost on anyone,
It's that this line of " our work too complex, we can't split it" is just tiresomely overused.

There are many ways to encouragingly ask " think of ways to break down the work into stories that fit into sprints" - evidently Ron's analogy did not work for you (this time).

Silvana 

On Jul 8, 2012, at 7:24 PM, Cass Dalton <cassdalton73 <at> gmail.com> wrote:

 

Im sorry that the analogy was lost on you.  I would love to tell you a real story.  Do you have a security clearance?

The basic question is not that complicated.  You have a single feature point that needs 20 man weeks of work behind it to provide real value to a user.  You have a team of 3 developers.

I can't imagine that no one in the agile community has not come across the situation where you are building a complicated system from scratch and it takes a number of sprints before the customer sees any visible value.  That's what the lawnmower analogy was designed to signify.  I did not expect people to get stuck in the technicalities of the analogy.

On Jul 8, 2012 11:57 AM, "RonJeffries" <ronjeffries <at> acm.org> wrote:
 

Hello, Cass,


On Jul 3, 2012, at 9:17 PM, Cass Dalton wrote:

The projects I work on are like this.  There is a single primary feature that requires a lot of work (i.e. multiple sprints) just to get a system that provides minimal customer value.  Once you have that, many of the follow on features start to roll off in good user stories.

So how do you split up these types of epics?

Are you building lawnmowers? In that case I don't know. If you happen to be building software, please tell us a real software story. We might be able to help with that.

Thanks,

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Charles Bradley - Scrum Coach CSP CSM PSM I | 13 Jul 2012 20:58

Re: How to split a story that doesn't have customer value when split

+1 to Silvana's comments.

There are a couple of catch 22's when it comes to discussing user stories in an online forum.
1.  How do you describe a mostly verbal technique(User Stories) using the *written* word?
2.  How do you convince people that you can split a story further, without the ability to know the dirty details about their story that are considered to be confidential for one reason or another?

Example #2 happens all the time on this list and I've seen it happen a lot on blogs and other forums like LinkedIn.

As one who studies and presents on User Stories, I often come across these catch 22's and I find it very difficult to deal with them.  OTOH, I love tough challenges(and User Stories!), so my brain continues to think on these topics.

My usual advice is to make up a fake (software) user story that represents the challenges you are facing, and then you play the PO role while we all drill down and collaborate to find ways to help your story.  I realize Cass has done that in a previous email, so when I have some time, I might try and dig into it.

As an aside, I've been fantasizing lately about filming some videos of people doing story grooming, but again, you run into the confidentiality problems.  Then, my next thought is coming up with some really good, detailed examples, without having to brea ch any confidentiality.  I think I could do that now, as I've seen some doozies.  Then, I could write a loose skit that some actors(my fellow Scrum enthusiasts, perhaps?) could act it out in a video, as a service to the worldwide community on what the User Stories practice is actually supposed to look like.  Or, maybe I could find a company that would be willing to video tape say 3-6 months of grooming sessions, and let us release those at a later date, once all of the confidential info doesn't really need to be confidential any more.  Ponder on this, I will.
 
-------
Charles Bradley
http://www.ScrumCrazy.com


From: SilvanaWasitova <wasitova <at> yahoo.com>
To: "scrumdevelopment <at> yahoogroups.com" <scrumdevelopment <at> yahoogroups.com>
Cc: "scrumdevelopment <at> yahoogroups.com" <scrumdevelopment <at> yahoogroups.com>
Sent: Friday, July 13, 2012 1:05 PM
Subject: Re: [scrumdevelopment] How to split a story that doesn't have customer value when split



Cass,

It's not that your analogy is lost on anyone,
It's that this line of " our work too complex, we can't split it" is just tiresomely overused.

There are many ways to encouragingly ask " think of ways to break down the work into stories that fit into sprints" - evidently Ron's analogy did not work for you (this time).

Silvana 

On Jul 8, 2012, at 7:24 PM, Cass Dalton <cassdalton73 <at> gmail.com> wrote:

 
Im sorry that the analogy was lost on you.  I would love to tell you a real story.  Do you have a security clearance?
The basic question is not that complicated.  You have a single feature point that needs 20 man weeks of work behind it to provide real value to a user.  You have a team of 3 developers.
I can't imagine that no one in the agile community has not come across the situation where you are building a complicated system from scratch and it takes a number of sprints before the customer sees any visible value.  That's what the lawnmower analogy was designed to signify.  I did not expect people to get stuck in the technicalities of the analogy.
On Jul 8, 2012 11:57 AM, "RonJeffries" <ronjeffries <at> acm.org> wrote:
 
Hello, Cass,

On Jul 3, 2012, at 9:17 PM, Cass Dalton wrote:

The projects I work on are like this.  There is a single primary feature that requires a lot of work (i.e. multiple sprints) just to get a system that provides minimal customer value.  Once you have that, many of the follow on features start to roll off in good user stories.

So how do you split up these types of epics?

Are you building lawnmowers? In that case I don't know. If you happen to be building software, please tell us a real software story. We might be able to help with that.

Thanks,

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell







__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
extremeprogrammer | 13 Jul 2012 20:23
Picon

Re: How to split a story that doesn't have customer value when split

One technique I've used occassionally (thrice in the last twelve years) is to treat information as
business value. Slice the story up to provide maximum information from each slice and then get to it. 

--- In scrumdevelopment <at> yahoogroups.com, Cass Dalton <cassdalton73 <at> ...> wrote:
>
> Im sorry that the analogy was lost on you.  I would love to tell you a real
> story.  Do you have a security clearance?
> 
> The basic question is not that complicated.  You have a single feature
> point that needs 20 man weeks of work behind it to provide real value to a
> user.  You have a team of 3 developers.
> 
> I can't imagine that no one in the agile community has not come across the
> situation where you are building a complicated system from scratch and it
> takes a number of sprints before the customer sees any visible value.
> That's what the lawnmower analogy was designed to signify.  I did not
> expect people to get stuck in the technicalities of the analogy.
> On Jul 8, 2012 11:57 AM, "RonJeffries" <ronjeffries <at> ...> wrote:
> 
> > **
> >
> >
> > Hello, Cass,
> >
> > On Jul 3, 2012, at 9:17 PM, Cass Dalton wrote:
> >
> > The projects I work on are like this.  There is a single primary feature
> > that requires a lot of work (i.e. multiple sprints) just to get a system
> > that provides minimal customer value.  Once you have that, many of the
> > follow on features start to roll off in good user stories.
> >
> > So how do you split up these types of epics?
> >
> >
> > Are you building lawnmowers? In that case I don't know. If you happen to
> > be building software, please tell us a real software story. We might be
> > able to help with that.
> >
> > Thanks,
> >
> > Ron Jeffries
> > www.XProgramming.com
> > Wisdom begins when we understand the difference between "that makes no
> > sense" and "I don't understand". -- Mary Doria Russell
> >
> >  
> >
>

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
jeffhoover@ameritech.net | 13 Jul 2012 20:47
Picon
Gravatar

Re: How to split a story that doesn't have customer value when split

Richard Lawrence, a member of this group, has a pdf with some great ideas about splitting stories:

http://rslawrence.wpengine.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

He points out several axes you can split stories along, including:
workflow
business rules
variations in data
data entry methods
performance
CRUD operations

For example: with CRUD I might have one user story that allows me to create a user account and another story
that allows me to change my password, and so on - I don't need a monolithic "create and update and delete my
account" user story.

--- In scrumdevelopment <at> yahoogroups.com, Cass Dalton <cassdalton73 <at> ...> wrote:
>
> Im sorry that the analogy was lost on you.  I would love to tell you a real
> story.  Do you have a security clearance?
> 
> The basic question is not that complicated.  You have a single feature
> point that needs 20 man weeks of work behind it to provide real value to a
> user.  You have a team of 3 developers.
> 
> I can't imagine that no one in the agile community has not come across the
> situation where you are building a complicated system from scratch and it
> takes a number of sprints before the customer sees any visible value.
> That's what the lawnmower analogy was designed to signify.  I did not
> expect people to get stuck in the technicalities of the analogy.
> On Jul 8, 2012 11:57 AM, "RonJeffries" <ronjeffries <at> ...> wrote:
> 
> > **
> >
> >
> > Hello, Cass,
> >
> > On Jul 3, 2012, at 9:17 PM, Cass Dalton wrote:
> >
> > The projects I work on are like this.  There is a single primary feature
> > that requires a lot of work (i.e. multiple sprints) just to get a system
> > that provides minimal customer value.  Once you have that, many of the
> > follow on features start to roll off in good user stories.
> >
> > So how do you split up these types of epics?
> >
> >
> > Are you building lawnmowers? In that case I don't know. If you happen to
> > be building software, please tell us a real software story. We might be
> > able to help with that.
> >
> > Thanks,
> >
> > Ron Jeffries
> > www.XProgramming.com
> > Wisdom begins when we understand the difference between "that makes no
> > sense" and "I don't understand". -- Mary Doria Russell
> >
> >  
> >
>

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
RonJeffries | 13 Jul 2012 23:39
Picon
Favicon
Gravatar

Re: How to split a story that doesn't have customer value when split


On Jul 8, 2012, at 1:24 PM, Cass Dalton wrote:

Im sorry that the analogy was lost on you.  I would love to tell you a real story.  Do you have a security clearance?

Not any more. I know now how to split all the Top Secret ESI AFR 205-15 things I did in the past, so I'm sure security isn't the issue.

The basic question is not that complicated.  You have a single feature point that needs 20 man weeks of work behind it to provide real value to a user.  You have a team of 3 developers.

You split it. It can always be split. Stories need to have visible value, in learning or partial progress, to the Product Owner. We don't actually have to launch a missile and blow up the Russians to write software one day at a time.

I can't imagine that no one in the agile community has not come across the situation where you are building a complicated system from scratch and it takes a number of sprints before the customer sees any visible value.  That's what the lawnmower analogy was designed to signify.&n bsp; I did not expect people to get stuck in the technicalities of the analogy.

I've been doing Agile for 15 years and have never encountered a story that couldn't be split into one-Sprint bits. This makes me quite confident that any story can be split. I'll mention one below. Maybe you can make up an example one that we can talk about without having to kill me after you tell me.

Chet and I were visiting a cable / communications company in a country north of ours. We were talking about stories and said, as we always do, that any work can be split into short Sprints showing value to the Product Owner. They said, "Not in our business." We said, "Tell us a story." 

They said "On-demand movies. Customer has new scr een menus, new buttons to push on his controller, we have to read the movie off the hard drive, stream it down a custom-assigned channel, blah blah. Can't do that in two weeks."

I said, "Do you already know how to assign a channel manually?" They said, 'Sure". I said, "Do you know how to read a movie from the hard drive and spit it down an assigned channel?" They said, "Sure". I said, "Do you know how to put a menu on the screen?" They said "Sure". 

I said, "How about if we assign some channel, 999 or something, and stream a single movie down that channel, over and over, so that anyone can go to 999 and watch it?" They said, "We could almost do that now."

Then the next stories might be some of these, in whate ver order the Product Owner wants:
  • Only let user 12345 see channel 999.
  • Only let users in the file AuthorizedUsers.txt see channel 999.
  • Put an OK button on the screen that if you click it, adds you to AuthorizedUsers.txt.
  • Assign a new channel when the guy clicks OK, so that he sees the movie from the beginning.
  • Add a second movie.
  • ... and so on

These stories look more and more like the real product, every couple of weeks. The PO can understand every one of them and can see them as progress. She can pick them to be done in any order that makes sense. She can start watching movies at her house after the fourth or fifth story.

My experience with this is always the same. People sit down and say their stories just cannot be split. I suggest a stupid way to split it. They say "That's stupid ... but what you could do is ..." and they're on their way. It happens so reliably I'm tempted to offer a guarantee that the team will have success doing it. I'm not willing to be shot, however, so it will help if we can try to work through some typical non-classified ones via email. For best productivity we might start with something other than the hardest and work our way up, but I really don't mind going either way. Thing is, I know how to do it for software, and so do a lot of people here. I don't know how to start from a firecracker and wind up with a nuke, though now that I think about it, I'm getting some ideas ...

Ron Jeffries
www.XProgramming.com
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg



__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Cass Dalton | 16 Jul 2012 17:43
Picon

Re: How to split a story that doesn't have customer value when split

I mentioned security only as a difficulty in coming up with an example, not as a difficulty in splitting the story.

Maybe my confusion comes from my interpretation of the combination of "deliverable software" and "customer value".  I read what's on the net and in books about stories and it feels like everyone pushes for deliverable end user value.  It makes sense that knowledge is also value, but you can't deliver knowledge.  And I get that spikes are sort of a special case of story that focuses more on the knowledge than deliverable software.  But in the example Ron describes, it seems to me that it was lucky that the customer could "almost do that now".  The place where I stumble is not an incremental improvement to an existing system, I have a hard time seeing how you stick to your guns about deliverable user stories when you're building the complex system from scratch.  Someone told me that they believed that agile works well when you're adding on to a system, but it works poorly when you are building something from scratch.  I see the logic behind that argument, but I really don't want to believe it.

In the cable company example, the first story is small because the existing system with all of its infrastructure is zero cost.  But what if it isn't?  What if you were running the software team that was involved in the initial cable system development?  There is a lot of development involved in getting even the simplest thin slice all the way through the system.  Which brings me back to my initial concern over splitting the stories:
I love the ideas of mocks to stub out the complexity or uncertainty, but if you are mocking pieces out, aren't you in danger of splitting on component or architectural boundaries?  I'm getting stuck on the idea of trying to split stories through all the layers of the cake when you're building the cake from scratch as you go along.  Maybe I'm taking the "deliverable software" part too literally.  I want to understand the best way to split the initial user stories when you're starting from nothing and the system is sufficiently complex.



On Fri, Jul 13, 2012 at 5:39 PM, RonJeffries <ronjeffries <at> acm.org> wrote:
 


On Jul 8, 2012, at 1:24 PM, Cass Dalton wrote:

Im sorry that the analogy was lost on you.  I would love to tell you a real story.  Do you have a security clearance?

Not any more. I know now how to split all the Top Secret ESI AFR 205-15 things I did in the past, so I'm sure security isn't the issue.

The basic question is not that complicated.  You have a single feature point that needs 20 man weeks of work behind it to provide real value to a user.  You have a team of 3 developers.

You split it. It can always be split. Stories need to have visible value, in learning or partial progress, to the Product Owner. We don't actually have to launch a missile and blow up the Russians to write software one day at a time.

I can't imagine that no one in the agile community has not come across the situation where you are building a complicated system from scratch and it takes a number of sprints before the customer sees any visible value.  That's what the lawnmower analogy was designed to signify.  I did not expect people to get stuck in the technicalities of the analogy.

I've been doing Agile for 15 years and have never encountered a story that couldn't be split into one-Sprint bits. This makes me quite confident that any story can be split. I'll mention one below. Maybe you can make up an example one that we can talk about without having to kill me after you tell me.

Chet and I were visiting a cable / communications company in a country north of ours. We were talking about stories and said, as we always do, that any work can be split into short Sprints showing value to the Product Owner. They said, "Not in our business." We said, "Tell us a story." 

They said "On-demand movies. Customer has new screen menus, new buttons to push on his controller, we have to read the movie off the hard drive, stream it down a custom-assigned channel, blah blah. Can't do that in two weeks."

I said, "Do you already know how to assign a channel manually?" They said, 'Sure". I said, "Do you know how to read a movie from the hard drive and spit it down an assigned channel?" They said, "Sure". I said, "Do you know how to put a menu on the screen?" They said "Sure". 

I said, "How about if we assign some channel, 999 or something, and stream a single movie down that channel, over and over, so that anyone can go to 999 and watch it?" They said, "We could almost do that now."

Then the next stories might be some of these, in whatever order the Product Owner wants:
  • Only let user 12345 see channel 999.
  • Only let users in the file AuthorizedUsers.txt see channel 999.
  • Put an OK button on the screen that if you click it, adds you to AuthorizedUsers.txt.
  • Assign a new channel when the guy clicks OK, so that he sees the movie from the beginning.
  • Add a second movie.
  • ... and so on

These stories look more and more like the real product, every couple of weeks. The PO can understand every one of them and can see them as progress. She can pick them to be done in any order that makes sense. She can start watching movies at her house after the fourth or fifth story.

My experience with this is always the same. People sit down and say their stories just cannot be split. I suggest a stupid way to split it. They say "That's stupid ... but what you could do is ..." and they're on their way. It happens so reliably I'm tempted to offer a guarantee that the team will have success doing it. I'm not willing to be shot, however, so it will help if we can try to work through some typical non-classified ones via email. For best productivity we might start with something other than the hardest and work our way up, but I really don't mind going either way. Thing is, I know how to do it for software, and so do a lot of people here. I don't know how to start from a firecracker and wind up with a nuke, though now that I think about it, I'm getting some ideas ...

Ron Jeffries
www.XProgramming.com
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg




__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
Alan Dayley | 9 Jul 2012 20:09
Favicon
Gravatar

Re: How to split a story that doesn't have customer value when split

There is value in allowing the customer to see and understand regular progress.

"For the first sprint we chose this engine from Briggs and Stranton.  See how well it runs? We also choose a combination blade and drive transmission to save weight and accelerate final assembly."

"This sprint we tested a new blade clutch that allows more blade types to be used than a usual clutch.  Here are the additional costs and benefits as we see them, what clutch would you like?"

"This sprint the transmission and engine are attached to the base chassis.  Stationary tests are favorable."

etc.

Create ways to show progress and value in each component so that your customer can provide feedback as you go, even if they can't yet "ride the lawn mower."

Alan

On Tue, Jul 3, 2012 at 6:17 PM, Cass Dalton <cassdalton73 <at> gmail.com> wrote:
 

In my continuing journey to understand the art of writing user stories, I'd like to present the following scenario that is analogous to the type of situation I deal with in our group.


Lets say your team is contracted to build a riding mower.  The main user story is "as a homeowner, I want to mow my lawn without pushing a mower". There will obviously be stories for features like better turning radius and adjustable blade height, but the first story that provides actual customer value (just having a riding mower to cut the lawn) will require a sizable team working multiple sprints just to get the mower working.  There are the wheels, tires, multiple components in the engine, the chassis, the blade, the steering, etc.  The system is so complex and the actual use case is so simple, that it feels like there is no good way to break up the first main user story.  You could write a story for the wheels (designing, machining, etc), and a story for the chassis, but these types of stories on their own don't provide any customer value.  You're supposed to slice up the big stories such that you get thin slices of all the layers in the cake, but in this type of complex system, I don't understand how you can do that.
The projects I work on are like this.  There is a single primary feature that requires a lot of work (i.e. multiple sprints) just to get a system that provides minimal customer value.  Once you have that, many of the follow on features start to roll off in good user stories.

So how do you split up these types of epics?




__._,_.___


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply |
headers
bazil_arden | 10 Jul 2012 10:08
Picon
Favicon

Re: How to split a story that doesn't have customer value when split

The way in which Wikispeed - used Scrum to quickly iterate towards the prize-winning 100 mpg car (with 5 star
safety rating) built by people across the world, shows how it is possible to delver value in increments
even on engineering projects
http://www.wikispeed.com/

It's an inspiring story and useful metaphor for many of the challenges we have explaining this stuff. 

--- In scrumdevelopment <at> yahoogroups.com, Alan Dayley <alandd <at> ...> wrote:
>
> There is value in allowing the customer to see and understand regular
> progress.
> 
> "For the first sprint we chose this engine from Briggs and Stranton.  See
> how well it runs? We also choose a combination blade and drive transmission
> to save weight and accelerate final assembly."
> 
> "This sprint we tested a new blade clutch that allows more blade types to
> be used than a usual clutch.  Here are the additional costs and benefits as
> we see them, what clutch would you like?"
> 
> "This sprint the transmission and engine are attached to the base chassis.
>  Stationary tests are favorable."
> 
> etc.
> 
> Create ways to show progress and value in each component so that your
> customer can provide feedback as you go, even if they can't yet "ride the
> lawn mower."
> 
> Alan
> 
> On Tue, Jul 3, 2012 at 6:17 PM, Cass Dalton <cassdalton73 <at> ...> wrote:
> 
> > **
> >
> >
> > In my continuing journey to understand the art of writing user stories,
> > I'd like to present the following scenario that is analogous to the type of
> > situation I deal with in our group.
> >
> > Lets say your team is contracted to build a riding mower.  The main user
> > story is "as a homeowner, I want to mow my lawn without pushing a mower".
> > There will obviously be stories for features like better turning radius and
> > adjustable blade height, but the first story that provides actual customer
> > value (just having a riding mower to cut the lawn) will require a sizable
> > team working multiple sprints just to get the mower working.  There are the
> > wheels, tires, multiple components in the engine, the chassis, the blade,
> > the steering, etc.  The system is so complex and the actual use case is so
> > simple, that it feels like there is no good way to break up the first main
> > user story.  You could write a story for the wheels (designing, machining,
> > etc), and a story for the chassis, but these types of stories on their own
> > don't provide any customer value.  You're supposed to slice up the big
> > stories such that you get thin slices of all the layers in the cake, but in
> > this type of complex system, I don't understand how you can do that.
> > The projects I work on are like this.  There is a single primary feature
> > that requires a lot of work (i.e. multiple sprints) just to get a system
> > that provides minimal customer value.  Once you have that, many of the
> > follow on features start to roll off in good user stories.
> >
> > So how do you split up these types of epics?
> >
> >  
> >
>

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |

Gmane