Tag: Scrum

Posted on by — Leave a comment

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.

Posted on by — Leave a comment

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
Posted on by — 1 Comment

eXtreme Programming Revisited (part III)

Extreme Programming InstalledWhen 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.

Ken Beck - Extreme Programming Explained5 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 logo-myfragilityXP practices in my framework My.Fragility, I decided to merge the best of both:

My.Fragility Grafx - XP Practices

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…

Posted on by — Leave a comment

eXtreme Programming Revisited (part II)

Extreme Programming InstalledTo 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!

Kent Beck - Extreme Programming Explained (Embrace Change)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‘), Kent Beck and Martin Fowler - Planning Extreme ProgrammingPlanning 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:

My.Fragility - 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)

*myfragility_logo 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.

Posted on by — Leave a comment

Introducing Scrum.org

Recently Scrum godfather Ken Schwaber resigned as chairman from the ScrumAlliance, which he co-founded.

Logo - Certified ScrumMaster SealI remember Ken from turning my ScrumMaster certification course in 2004 into a great experience. Not because of the certificate, but for comprehending Scrum. I’ve since then advised people to attend the certification course, but mainly to get in touch with other people and dive into the matter.

Scrum.orgKen launched Scrum.org as a move from ceremony and formal organization to process and community. From certification to assessment (for self-improvement). There’s an online Scrum Assessment (note: no longer available), upon a Scrum Guide. Because… “Unlike certification, assessment makes no public claim of competence and cannot be misused to assert qualifications that may or may not exist“.

I scored 69 out of 80 (86%), which took 25 minutes (1h allowed). This feels okay but the most important aspect was that through the reflection on some missed points I could improve my insights.

“Although there’s value in certification, assessment is valued more.”

Posted on by — 2 Comments

Definition of… Agile Planning

In The adoption of Agile I stated that ‘Agile’ is not one method, but a set of common principles and practices. The same goes for ‘Agile Planning’.

I created my My.Fragility framework iteratively over the various software development projects I mastered, all serving to realize a (negotiable) scope within a certain timeframe.

The included Product Backlog Estimation model allows to:

  1. Write User Stories. Or Epic Stories
  2. Make up estimates in Ideal Time / Story Points
  3. Determine Velocity. Possibly, but not advisable, per story
  4. Determine #pairs. Consider project elapse time, max = 6
  5. Determine #FTE for umbrella tasks. Upon #pairs and complexity
  6. Set daily rates
  7. Set slack, holiday percentage and coach development
  8. Assess result & iterate using other parameters
  9. Set Value of Stories. Total to be 100 (for relative tracking)

The Product Backlog Tracking model implements my Tracking Loops:

My.Fragility - Tracking LoopsThis assures a continuous image of spent and expected progress, effort, budget and delivered value, at Product and at Sprint level.

Mike Cohn - User Stories AppliedThe book User Stories Applied by Mike Cohn was a great source of inspiration. Essentials I still use are:

  • User Stories, Epic Stories and micro (tiny) Stories
  • The INVEST acronym
  • Complexity scaling. I use ‘1-2-5’ (over Fibonacci)

Mike’s publisher (Prentice Hall) has made 2 chapters of his second book Agile Estimating and Planning available, for F R E E:

Posted on by — 1 Comment

The adoption of Agile: TALC vs. Hype Cycle

An interesting poll was posted at Scrumology asking us to indicate where we consider ‘Agile’ to be on the Hype Cycle. A little note…

logo-myfragilityThe presentation of my framework My.Fragility starts with a general introduction on ‘Agile’ before diving into Scrum and going beyond. This introduction ends with a maturity assessment of Agile using Geoffrey Moore’s Technology Adoption Life Cycle. The conclusion is that Agile has Entered the Bowling Alley (so has definitely Crossed the Chasm).

In 2008 I added a comparison with Gartner’s Hype Cycle for Application Development, which puts Agile in the Trough of Disillusionment and predicts a period of 5-10 years before mainstream adoption.

Agile on the Hype Cycle for Application Development 2007 (Gartner)

However, having studied and compared both models I am convinced that Agile is -at least- on its way to the Slope of Enlightenment:

Agile on the Hype Cycle vs. TALC

Other objections I have with Gartner are:

  • Agile is primarily the common denominator of a number of methods and is as such not one defined method. As a practitioner of Scrum, combining it with XP and going beyond with My.Fragility, I believe these methods to be certainly farther in adoption.
  • A complete Agile approach covers a number of practices and disciplines that Gartner separates (e.g. various testing levels). See my indications on the Hype Cycle.
  • My intuition and daily experience contradict the 5-10y expectation.

Challenge: from the TALC I expect Scrum to become the Agile Gorilla…

Posted on by — Leave a comment

The spell of the Man-Month broken?

Brooks - The Mythical Man-MonthFrederick Brooks published his essay The Mythical Man-Month in 1975, as one of 15 essays in the same-titled book on managerial aspects of software development. I wanted to check on the actual value of this historical piece of work. I have read the 20th anniversary edition, to which the author added an essay with his updated opinion on his original statements. This edition also holds the even more known 1986 paper No Silver Bullet.

The book: modern myth or ancient history?

The 1975 cases are technically not appealing (IBM’s OS/360) and hardly relevant for today’s technological environments. But the organizational topics are striking, with the title essay on top (justly mythical by itself). Although the core statement (“Brooks’ Law”) “Adding manpower to a late software project makes it later” has again been overtaken by history. But blame the myth of the man-month for confusing effort and progress, for neglecting the need for communication, for ignoring repartitioning tasks and training, and decreasing team productivity. People (developers) are not ‘replaceable pieces of machinery ‘! Brooks also stresses the creative nature of software development.

I agree on the diagnosis, but the suggested remedies (a lot on estimating and roles) are somewhat vague and far-fetched. E.g. 1/6 = coding, surgical team and ‘directors’/‘producers’, ‘aristocratic’ architects, etc.

But then, there’s the author’s 1995 retrospective seeming to make the lecture vivid again. He formulates views that are greatly in line with… Agile. But then (bis), Brooks doesn’t seem to recognize it and sticks to his ancient solution, i.e. a sort of surgical designers. But since the ‘90s we hàve seen the definite rise of Agile (this common denominator was only established in 2001!).

Can we today overcome the curse of the mythical man-month?

I believe that at least Agile does show a way out! Of the problems highlighted by Brooks, but in a very different direction than surgical design. Because Agile has a fundamentally different approach on communication and the ‘people’ aspect of software development.

e.g. Estimating is done by the whole team and in Story Points, i.e. complexity. This is at the same time the base for measuring progress (i.e. velocity being the number of Story Points realized in a Sprint), and avoids the confusion with effort.

In his Agile bible, Agile Software Development, Alistair Cockburn has substantially stressed the fact that communication hàs a cost, increasing our awareness of the impact on progress and budget. His views on Information Radiators and Osmotic Communication have meanwhile been greatly adapted by Agile teams.

Posted on by — 2 Comments

Scrum (all sorts of people)

logo-myfragilityScrum is also in the minds of people. My mind is set on the ability of fragility. How about you?

Are you ‘management’? Then you should not only be willing to believe that a software project can truly deliver quality and business value. You should also do (a lot) more than just gather a group of programmers with a project manager on top during a (project’s) timebox.

Okay, so far for a view the community will quickly agree upon.

What is usually less focused on is the level of commitment of the actual team members. In my experience this may turn out to be at least as difficult to achieve. Because it takes the absolute will to self-organize, not wanting to depend on other people to take decisions for you (the essence of ScrumMaster facilitation versus Project Management’s execution of control), to outweigh every (technical) choice against the (business) value and functional profit, to discuss and communicate openly, etc.

Scrum is a simple way to outperform and excel but all parties should respect its essence, that I represent on my Scrum Diamond:scrum-diamond

think (talk) about it…

Posted on by — 2 Comments

Kanban and Scrum (done or to be done?)

Kan and Ban are Japanese for Card and Signal. A Kanban (signal card) originates from the Toyota Production System (TPS) where it is a physical card that visualizes a pull question for inventory. It serves to minimize stock in a ‘Just In Time’ strategy and is a way to ‘eliminate waste’ while assuring a continuous flow of goods.

In an Agile context, a Story Card is a Kanban. Out of eXtreme Programming it grew into an established Agile practice in describing a feature. A Kanban Board holds the active Story Cards per ‘status’, thus being an Information Radiator (term by Alistair Cockburn, also my inspiration for the Games metaphor).

My.Fragility_logoMy Scrum Product ànd Sprint Backlog items are User Stories. (‘Minimal Marketable Feature’ is more generic, but I stick to ‘User Story’) The Sprint Backlog is made visible by sticking a printout from my (Excel) tracking model on a wall. Around the Daily Scrum (we do it standing up) each Story Lead writes the estimated time to finish a Story on the printout and I create the Sprint Burndown. That works fine. We use a Kanban Board only for feedback from functional testing. This is generally too small to create a Story (would be ‘waste’).

Velocity is a way to optimize the inventory and the continuity of work. Traditionally ‘velocity’ equals the #Story Points (gummy bears) that can be finished in one iteration (a Sprint). However, I apply an overall Velocity as a multiplicator on Story Points (ideal time) to result in #planning days. The size of the inventory (in #Story Points) for a Sprint is determined by dividing the available #planning days of a team (minus 2 slack days) by expected Velocity (Yesterday’s weather). Note: continuity is also assured by the presence of the Product Owner. He/she makes sure that no functional issue remains unsolved, on the spot!