The sizing of User Stories

My My.Fragility framework adds my insights for fixed price (-negotiable scope) projects to XP and Scrum.

I included a Product Backlog Estimation model to calculate a total price using my Definition Of Agile Planning. And on top of User Stories and Story Points the Sizing of User Stories is to be considered:

The right size of a User Story is 0,5-5 ideal days (di) (ideal time = Story Points). For development. To be invEST. To comfortably fit a Sprint.

• Epic Stories can be 5-15 di. A size not suited for development but acceptable for estimating. To be split into User Stories.
• Cosmic Stories are >15 di. They can serve only as a beginning to understand a Product, not for estimation or development.
• Tiny Stories are < 0,5 di. To be combined into User Stories.

Note: ‘Minimal Marketable Features’ (MMF) from Kanban can be a set of User Stories. Possibly an Epic Story.

The best base to estimate is experience. When experience is limited, use relative estimates (complexity scaling). I use a 1-2-5 scale:

• Size is set upon complexity to 1-2-5-10-20-50-100-… Always use the higher value if you end up in between two points.
• Find some reference points in your experience to compare.
• Refine until you end up with real estimates (Story Points).

note: Ideal time is development time without breaks, questions, problems or any interrupts. It is multiplied with Velocity to get Planning days.

Peter knows which way to go

Peter knows which way to go. And not only because his spaceship knows.

On his personal, newly established, music label Huvolla Peter Murphy has been releasing some Secret Covers, named after his latest concert tour. It started with the John Lennon classic Instant Karma, that was also used in a (JP Morgan) commercial.

Then came David Bowie’s Space Oddity. Peter added his special oriental feel; the one in which his CD Dust was already… covered. The distinct electric violin of Hugh Marsh re-appearing after Dust and Peter’s -incredible- live album Alive (Just For Love).

Next, Peter released the live and cracklin recording (with his band) of Joy Division’s Transmission, performed at the Highline Ballroom (NYC) in July 2009. I remember Bauhaus playing “Isolation” live during their last tour (ever), with Peter already copying some of Ian Curtis’ typical gestures.

Both as solo artist as with Bauhaus, Peter has performed on a number of occasions with Nine Inch Nails. He performed Hurt with Trent Reznor at a radio (FM live) session. I downloaded that one for free. Peter now released it as secret cover #4. And I bought it. Being a collector-fan and to support Peter.

Peter Murphy is a remarkable voice in today’s musical landscape, a position he rightfully gained by being an expressive, committed and original artist. Not because he’s god. Because there is no god.    But god.

Definition of… Story Points

I have combined personal insights for fixed price (-negotiable scope) projects with practices from eXtreme Programming and Scrum in my My.Fragility framework.

The main estimation steps from the framework’s Product Backlog Estimation model were highlighted in my Definition Of Agile Planning. But the model also implies at least an understanding of some definitions.

After my definition for User Stories here’s how I use Story Points:

• Story Points equal ideal time (“ti”). But using ‘Story Points’ might prevent people from confusing it with realistic time. The eXtreme Programming notion of Gummy Bears (“Bg”) might be a bit too abstract, although it’s fun to use.
• Ideal time is the development time for a User Story without breaks, questions, problems or interrupts of whatever nature. Spending every minute of every working day on productive coding.
• Ideal time is mulitplied with Velocity (“v”) to estimate Planning time (“tp”). In my experience, an overall velocity of 2,5-3 results in a realistic number of planning days.

planning time (“tp”) = ideal time (“ti”) * Velocity (“v”)

• An alternative definition of Story Points is the number of productive coding hours per day. This is generally accepted as maximum 5-6. Velocity is then expected to be around 1,33.

Note I generally apply an overall Velocity to all User Stories, although my model allows a specific Velocity per User Story, e.g. depending on the expected complexity.

Definition of… User Stories

Over various projects I have applied a set of Agile practices from eXtreme Programming and Scrum. Adding personal insights to specifically handle fixed price (-negotiable scope) projects resulted in my My.Fragility framework.

The framework includes a Product Backlog Estimation model, for which the main estimation process steps were highlighted as part of my Definition Of Agile Planning. Furthermore does the model at least imply an understanding of my definition of a User Story:

A User Story describes a feature from an end-user perspective. It is independent of software layers or parts of the project

A User Story can be explained as an essential Use Case

A User Story should be INVEST to be ready for development

• Independent: User Stories have as little interdependence as possible. Resolve it by putting related Stories in the same Sprint
• Negotiable: a User Story is an invitation to discuss implementation. The best design and code result from communication!
• Valuable: a User Story represents effective business value for an end-user
• Estimatable: the size and knowledge on a User Story is sufficient to reliably estimate the Story
• Small: a User Story is small enough to be estimated, developed and tested. It is comfortably realizable in one Sprint
• Testable: a User Story has a clear result that can be tested

Lovelornalimbo

1989. A man. Boy. No real man (not like fathers). Locked. Away. Stares. A river. Cries. A river. Need to sleep. Love lost. A fool romantic. Tortured heart. Could have been so good… for you. Eyes that see the world. I have no words. The moon looked down.      And laughed.

2004. Gavin Friday finally succeeds in re-releasing, re-arranging, extending and re-shuffling the complete Virgin Prunes back catalog.

The Moon Looked Down And Laughed got new artwork and Just A Lovesong, the most honest lovesong ever (previously only a ‘rarity’ on Over The Rainbow). Courtesy of Dave-ID and Dave Ball. True Life Story remained with its crazy growling in Russian by Mary’s girlfriend (not on LP but on the New Rose CD). White History Book deleted (previously on the B-side of my “Don’t Look Back”-EP and the New Rose CD).

Preferring Lovelornalimbo (previously on my Our Love Will Last Forever Untill It Dies-EP only) over Love Lasts Forever ultimately removes a slick feeling of compromise. Away with the slightest doubt if -6 years after the Red Nettle statement- they had secretly tried to be ‘the new pop sound of Ireland‘ after all. Sir Poddington beheaded as a treacherous knight.

2009. Still love it! Gav settled things. No sacrilege. No harm done. But I still feel that The Hidden Lie is worthwhile… but Gavin doesn’t. Who am i?

The Big Ask (Again)

Hier is de vraag, again. Met een dansje (enfin, 12.000 dansjes). Waar blijft het antwoord?

Kippenvel (knappe montage overigens). Dus open je ogen, toon je, via de website, via Facebook, lees Nic Balthazar, loop storm… want vele druppels maken een VLOEDGOLF.

eXtreme Programming Revisited (part III)

When reviewing Chet Hendrickson’s paper on the evolution of Extreme Programming practices, I was surprised that he completely ignored Kent Beck’s revision of 2004. As does Ron Jeffries’ practices representation, by the way.

5 Years of eXPerience resulted in a complete revision of Extreme Programming Explained. The general tone softened, partial adoption became acceptable and the practices were extended, and divided into primary and secondary practices. Maybe Kent considered XP as under-adopted, but I missed the strong and ahead leadership from v1. No compromise. Working software is the goal. Extreme focus. Programming is the way.

I also felt that in the v2 edition, good ideas were introduced, but good practices were also replaced. Because I instantiate Scrum’s engineering standards with XP practices in my framework My.Fragility, I decided to merge the best of both:

Note: when checking the original Extreme Programming Installed book myself, I wondered (after all these -6- years!) why it did not mention the Coach role. When moving to Scrum after our ‘pure’ XP application, I kept promoting this role. I still do in my My.Fragility framework (on top of Scrum’s Product Owner, Team and ScrumMaster).

And I still don’t known why User Stories was not an explicit XP practice from the beginning…

eXtreme Programming Revisited (part II)

To review Chet Hendrickson’s retrospective paper on his book Extreme Programming Installed, I went back in time myself. Back to my first experience with Extreme Programming.
In September 2003 I was asked to urgently take on a project as project manager. Customer approval was late but the predicted delivery date remained (December).

A 15 min introduction convinced me of eXtreme Programming. Because so much was incorporated that was traditionally so easily forgotten or overlooked. We convinced management, and off we went (October). After 3 iterations (of 3 weeks) we delivered… in time and on budget!

Because I considered myself too illiterate (after all, we only did it) to present the project at Javapolis 2003, I started reading some books. The inevitable Extreme Programming Explained (‘Embrace Change‘), Planning Extreme Programming and… Extreme Programming Installed. It was remarkable to find that our ‘naive application’ was an extraordinary match with what I was reading. Presentation went very well.

In 2004 I started using Scrum as process and certified as a ScrumMaster. During follow-up projects for our satisfied customer we kept combining Scrum and XP. However, we had to operate within a context of realizing a (negotiable) scope in a given timeframe. So along the way (2004-2006) additional practices, tools and views were embedded, to finally become my My.Fragility* framework.

The framework holds following (partially XP based) Quality Loops:

Implementation of Engineering Standards. To be performed every day:

• A pair writes all code upon a Test First basis (including Selenium GUI tests)
• Checked in code is tested in a Continuous Integration system (multiple times a day) and can be refactored
• A ‘guide’ (additional, explicit role) functionally tests a stable, CI’ed version (multiple times a day) and feeds back results to the team
• A functional working version may be deployed for performance testing (running overnight)

* The name of the framework has its roots in the big relief I felt when morphing from project manager to ScrumMaster. The option to be fragile (agility through fragility), of not constantly having to intimidate people. Because, after all, it’s just a matter of talents and roles, not of… hierarchical slavery.

eXtreme Programming Revisited (part I)

Chet Hendrickson is the co-author of the book Extreme Programming Installed (2001). In a paper of August 2009 he discusses the XP practices he feels that have changed over the last 10 years.

That triggered me to have a small retrospective myself.

I’ve read this book in November 2003 as research for my presentation at the BeJUG’s JavaPolis of December 2003. I presented a major project in which we (very successfully) applied eXtreme Programming (truly pioneering in Belgium at that time). I read the book after Kent Beck’s books in the same series, Extreme Programming Explained (Embrace Change, 1999) and Planning Extreme Programming (2000).

Looking back today, I still find that Extreme Programming Installed lacks structure, leaves an impression of randomness, misses a good ‘story’. I distinguish 3 main parts, without these parts being marked as such:

• Introducing XP with the 4 XP values (communication-feedback-simplicity-feedback), the roles (customer-manager-programmer) and highlighting the On-site Customer and User Stories
• In-depth description of the 12 XP practices (13 actually as Testing was split into Acceptance Testing and Test First)
• Bonus Tracks with some of the authors’ highly personal experiences and coding insights

Although the practices are core, they are only listed at the end and the coherence is mostly neglected. Although co-author Ron Jeffries drew a perfect roadmap with his alternative to Kent Beck’s representation:

My remarks on the changes that Chet identifies, are:

• Views on User Stories Size have indeed evolved. My Definition of Agile Planning mentions Mike Cohn’s influence. But in Planning Extreme Programming Kent Beck & Martin Fowler had already treated the essential topics (including sizing) surprisingly well.
• The Iteration Length (originally 3 weeks) has equally been given flexibility. The same goes for Scrum (30 days Sprints), that I started applying in 2004. I mostly stick to calendar month Sprints.
• I agree that the Metaphor guideline has not been well adopted, despite its potential. But did it ever stand a chance, as even Extreme Programming Installed treated it marginally?
• The topic of Dispersed Teams has really grown in importance. But no method (Agile or other) has ‘the’ solution. Alistair Cockburn has at least published remarkable thoughts on the communication aspects. I still refer to his Osmotic Communication.

And… I agree that the C3 pioneers have changed the world by the formal introduction of eXtreme Programming!

But… Chet nor Ron mention Kent Beck’s profound XP revision of 2004. I’ll come back on that in eXtreme Programming Revisited (part III).

De finesses van de genetica

Erfelijk of niet erfelijk, dat is het vraagteken. Omdat genetica verwarrend kan zijn. Duchenne is genetisch èn erfelijk. Down is genetisch, maar niet erfelijk (enfin, onze vorm toch niet). Zot zijn van lego is een twijfelgeval. Ik ben zelf nogal into Lego Batman. Is de fascinatie van onze oudste zoon voor Lego Clone Wars dan erfelijk of opvoeding (indoctrinatie)? Het doet alleszins geen zeer. Behalve soms in de portemonne. Moet kunnen voor een 8e verjaardag.