story for basic setup of new subsystem

[dotnetguy]

Hello, some new subsystems can be complex and require a fair amount of basic infrastructure work to set up to get started. 2 weeks may not be enough time to develop/deliver features of this subsystem to the business. That being said, would the following story be acceptable or would you take a different approach:

“As an invoice processor I want a basic program infrastructure upon which special features, logic and handling can be built”

[Ron Jeffries]

On Mar 7, 2015, at 6:52 PM, dotnetguy <andrew.d....@gmail.com> wrote:

Hello, some new subsystems can be complex and require a fair amount of basic infrastructure work to set up to get started.  2 weeks may not be enough time to develop/deliver features of this subsystem to the business.  That being said, would the following story be acceptable or would you take a different approach:

“As an invoice processor I want a basic program infrastructure upon which special features, logic and handling can be built”

No. that is not a story. A story must express business value as seen by the Product Owner.

P.S. I have never encountered, in a half-century of software development, a problem such that some visible step toward value could not be made in one Sprint. Let me put that the other way: it is always possible, IME, to produce visible business value in one Sprint.

Ron Jeffries

ronjeffries.com

Before I start arguing with somebody, I try to save them a little time by letting them know that I’m usually right about stuff.

— Andy Richter

[dotnetguy]

Hi Ron, let's say you were the SC for this project and this story was proposed to you. What specific questions would you ask or what specific actions or next steps would you recommend for this problem in order to deliver business value at the end of the sprint?

[Ron Jeffries]

DNG,

On Mar 7, 2015, at 8:04 PM, dotnetguy <andrew.d....@gmail.com> wrote:

Hi Ron, let's say you were the SC for this project and this story was proposed to you.  What specific questions would you ask or what specific actions or next steps would you recommend for this problem in order to deliver business value at the end of the sprint?

What is an SC?

Why is whoever proposing this proposing it? What real story does it support? Where is the PO? What does the PO want?

Ron Jeffries

ronjeffries.com

You never know what is enough unless you know what is more than enough. -- William Blake

[dotnetguy]

SC = Scrum Coach

"Calculate Invoice" is a subfunction-level use case which has many interrelated use cases.

@Ron - Have you ever built a complex invoicing system from scratch using Scrum? If so then can you describe the approach you used?

[Ron Jeffries]

DNG,

Built a corporate payroll, which makes invoicing look like a toy. The project was called C3 and was the first Extreme Programming project. 

Our first story, which took less than one iteration to do, was “Calculate Joe’s Paycheck”. Joe got paid some fixed amount of money and we charged him 25% income tax, and printed an actual check.

An invoice, when you get down to it, is a very simple thing. It is an itemized list of goods or services, summed, sent to some entity. The first one might look like this:

BIG COMPANY Invoice

TO: Little Company, 123 Main Street, City, State, ZIP

Dt: 8 Mar 2015

Items

——

$123.45 Thing One

$234.56 Thing Two

———

$358.01

Due Upon Receipt

Working in Ruby, I could create that invoice in an hour. Working in C#, it might take all day. (Sorry about that.)

At the very beginning, I’d be inclined to a one-week or shorter iteration with a handful of decent programmers, and I’d think they could do a bunch of stories like this:

• Produce Sample Invoice shown above for Big Company
• Rudimentary Customer Object (in memory)
• Customer Name, address, …
• List of Items
• Item Name, Price
• List of Customers (in memory)
• List of Items per each
• Support Quantity larger than 1
• Support Standard Quantity Discount (list in memory)
• Support by-Customer Quantity Discount (list in memory)

By way of comparison, when Chet and I teach a Certified Scrum Developer course, the teams of four to six people produce a payroll system that supports multiple employees, accepts separate hourly rates for each, separate hours in each pay period, deducts rudimentary social security, federal, and state tax, deducts occasional company deductions such as lost badge or purchase of safety shoes, and which produces annual and quarterly running totals of the various numeric fields, by employee and company total. 

How much time do they get? We run iterations of about ninety minutes. They complete, typically, a couple of stories per iteration. We generally get two iterations per day, with the rest of the time taken up reviewing test results, doing retrospectives, reviewing the code, and so on.

Teams manage to finish around a half-dozen stories of this nature, doing TDD and ATDD on everything, in about five or six 90 minute iterations.

Every single story they do makes sense to a payroll person and shows visibly correct payroll calculations for multiple employees, starting from the first story.

It turns out that stories can be sliced very thinly, such that every single one can be understood by the domain expert.

Your original question was about infrastructure. Hints were given above: early stories run on lists created in memory. What’s the difference between a list in memory and a database? Well, with even a half-hearted bit of abstraction, there is no difference. Get the next Customer, Fetch his items, Fetch each item details, print. List, database, no difference other than down below.

So a story an iteration or two later becomes:

• Get Customer List from file, or
• Get Customer List from database
• Get invoices …

Once we write the simplest possible loop for invoicing ...

  For customer in CustomerList

    total = 0

    For item in ItemList

      Print Item (customer, item)

      total += item.price*item.quantity

    Print total

… we can elaborate that loop’s details by refactoring and adding new functionality, which will mostly fall in the right place because the overall structure is close to right from the get-go. In other words, we just plug in a different way of getting the customer list and iterating it, a different way of fetching the items and iterating them, and so on.

Teams learn to do this quite readily in a Certified Scrum Developer course, which takes five days. So I’m sure you can do it. It takes practice to get good at it and training generally helps, mostly by getting people past the stage of not believing it can be done.

So my advice is, don’t try to work your way from waterfall to Scrum. Just do Scrum. Finish real business-oriented stories in two weeks. At first, you’ll suck. That’s the point, because soon you won’t suck any more.

Ron Jeffries

ronjeffries.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[Dan Rawsthorne]

I think that's a perfectly fine story (not a user story, though). It provides value to the Invoice Processor, and the PO can now decide if it helps maximize the value of the team's work.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[John Miller]

I am failing to grasp how this adds value to the Invoice Processor. 

Thank You,

John Miller

Agile Classrooms

Clarity.Choice.Collaboration

AgileClassrooms.com

[Ron Jeffries]

Just so.

On Mar 8, 2015, at 6:28 PM, John Miller <agiles...@gmail.com> wrote:

I am failing to grasp how this adds value to the Invoice Processor. 

Ron Jeffries

ronjeffries.com

I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

[Nigel Baker]

I am failing to grasp how a PO would prioritise such a story.

Nigel

(Beyond "badly")

[Dan Rawsthorne]

He says it does, not our job to second-guess him/her. Now we start refining the story to figure out what it really means... The question was whether or not it gets in the backlog...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

Well, first you refine it to figure out what it means, decompose it, rewrite it, and so on... then you decide if it (whatever it is now) is next or not.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Ron Jeffries]

Dan,

On Mar 9, 2015, at 12:05 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

He says it does, not our job to second-guess him/her. Now we start refining the story to figure out what it really means... The question was whether or not it gets in the backlog...

It is our job to educate the OP and his associated PO. Call it second-guessing if you like, but that’s why people ask and why we try to give them better advice than “OK go ahead then”.

Ron Jeffries

ronjeffries.com

Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[Dan Rawsthorne]

Yes, it is our job to help people understand what the PO's job is, and what self-organization is. In this case, I think the thing to do IS 'go ahead then'. We are finally getting to the crux of the question, which is 'what do we do with silly-looking PBIs?" Then we could talk about refinement. But simply saying "don't allow silly-looking PBIs" is not useful, IMHO.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[John Miller]

I agree with self-organization. I also think the PO can have anything they want in the backlog. 

I heard a different question than what you heard. I heard a request for feedback on the story and the approach itself, upon which, many of us are trying to meet that request. 

Thank You,

John Miller

Agile Classrooms

Clarity.Choice.Collaboration

AgileClassrooms.com

[Dan Rawsthorne]

Ah

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work