Helpful Tips for Splitting User Stories

Splitting user stories require creativity and the right tools.

Being a product owner is hard work.  It is days filled with meetings and writing user stories.  You are under pressure to deliver working software, and if it all goes wrong, your career is often at risk.  One of the hardest parts about product ownership is a collaboration with the development team and estimation.  Software developers are notoriously hard to work with, and estimating software development is exponentially more difficult.   The estimation process is fraught with conflict and compromise.  Often, work is too large to be completed in the time box of a sprint.  The product owner in this situation should split user stories.  Today, I want to share a common technique to divide user stories.

I have a relatively straight forward process for writing user stories.  Once you write a story, the development team should try to estimate the story.  A story point estimate is a function of complexity, risk, uncertainty, and effort.  According to Kedar’s constant, the larger a story is in points, the riskier it is to complete in a sprint.  It means a set of four three-point stories are less risky to complete than a single 13-point story.  When you have essential stories with high point values, it is up to the development team and scrum master to request the story get split before sprint planning.   The product owner is often frustrated by this request. Breaking stories is additional work, and it implies the original story was too big.  I empathize with this kind of frustration.  Being asked to split a story is the team being conscientious.  It is also an opportunity to make the sprint more successful.

Richard Lawerence has written a fantastic post on how to split user stories.  I recommend you read it here.  For me, the most critical pattern is to break down work based on complexity.  Something complex is often the assemblage of smaller, more straightforward elements.  Suppose you are a sales manager for a cable T.V. station, the base rate for a 30-second commercial is $150 per broadcast so when a client purchases ten impressions they are invoiced $1,500 when the last commercial airs.  If you are going to write a user story with acceptance criteria, it will look something like this:

As a sales manager, I want to charge $150 per impression for a 30-second commercial because I want to generate revenue.

GIVEN I am a customer.

WHEN I purchase a 30-second commercial.

THEN I invoice $150 times the number of commercials purchased.

The rule is simple, and the team says following SOLID principles and authoring unit tests it would be two points worth of work.

The world of broadcast is time-sensitive, so commercials air during prime time between 6:30 PM and 10:00 PM are more valuable while ads aired after midnight are less costly.  The product owner realized this and added two more acceptance criteria to the story.

GIVEN I am a customer.

WHEN I purchase a 30-second commercial.

AND the commercial airs during prime time between 6:30 PM and 10:00 PM

THEN I invoice the customer $150 times the number of commercials
purchased plus a 40% premium fee



GIVEN I am a customer

WHEN I buy a 30 second commercial

AND the commercial airs during late night (between midnight and 5:30 AM)

THEN I invoice the customer $150 times the number of commercials 
purchased with a discount of 20%

During sprint planning, the team looks at the revised user story with the additional acceptance criteria, and they adjust the story points to eight because the story has become more complex.  A good rule of thumb I like to use for splitting user stores is anytime you see the contractions “and” or “or” it is an excellent place to divide a user story into smaller stories.  In the above example, one eight-point story, when divided into three stores with an estimate of two, each generates less risk for the sprint.  The story split also makes budgeting work easier.

Splitting user stories is a useful skill, and it helps make the development team more successful.  Start breaking user stories today.

Until next time.

Agile, Story Points and Rock-n-Roll

The Crüe are very rock-n-roll and agile.

Being an agile coach is filled with plenty of touchy-feely moments.  You have to deal with difficult emotions and move change through an organization which is satisfied with the status quo.  Other times a coach or scrum master must deal with the practical matters of scheduling a meeting and facilitating a retrospective.  Finally, you are learning new things and applying them to your clients.  My vision of how story points work has changed over the years.  Recently, I am looking at story points in a new way, and it is good enough to share.

My first thoughts about story point made me think of them as measures of volume.  A story point contained a certain number of hours, and it would be easy to convert the two back and forth.  After my first 18 months of being a scrum master, I saw the folly in that way of doing things.  It became apparent that story points represented something analogous to distance.  An Olympic runner can cover 3,000 meters in under four minutes.  I can walk it in about a half hour.  Story points provided a quantitative way to measure uncertainty and help communicate to upper management.

Now I see a story point as the sum of four factors; complexity, risk, effort, and uncertainty.  We sum all these factors together and round them up to the nearest whole number in a Fibonacci sequence.

So if I wrote it out a math formula it would look like this:

Story Point = Complexity + Risk + Effort + Uncertainty
F_N = [Story Point]

Where F_N is a number in a Fibonacci sequence.

The new acronym for this is CRÜE, after the rock band Mötley Crüe.  By today’s standards, this giant of 1980’s glam metal would flame out in the public eye.  The band was nihilistic, misogynistic, and poster children for the destruction of alcohol and drugs could do to a person.  Finally, the lead singer killed someone in the act of vehicular manslaughter.  In spite of all the baggage, you could count on the band to put on a great show.  You could also count on them to be blaring out of any stereo at a house party during the 1980s. People of a certain age have memories of significant life events happening with Mötley Crüe playing in the background.

As an agile coach, I will let the young people concern themselves with sex, drugs, and rock-n-roll.  It is not my lifestyle.  I prefer agile, story points, and rock-n-roll.  If you are talking about story points, talk about Crüe; complexity, risk, uncertainty, and effort.

Rock on people and until next time.

Estimation is not an alibi for failure.

Estimation is not a quotation of work.

I spend plenty of time working with people who are just learning about agile and scrum.  The agile reformation has spread worldwide; what it has not done is penetrated deeply into organizations.  Elite information technology teams quickly accept the new paradigm and start to deliver.  Executives and leadership notice and they want to replicate these effects in the organization.  It is when this happens the life of a scrum master gets complicated.  If agile is going to succeed at scale in large organizations leadership must change how it views work.  It begins with accepting all estimations are not quotations for labor. 

Ryan Ripley, a coach, and trainer I respect is an advocate of the “no estimates,” camp of agile.  I have blogged about this school of thought, and I consider myself a skeptic.  I think it is easy for a team to operate without estimating but executives who are paying the bills are horrified when highly paid professionals say they do not have an educated guess about when they will finish work. 

The reality is executives are craving certainty in an uncertain business world.  An executive wants to know the budget is not getting wasted.  Most executives do not understand the technology which keeps their organization workings, so this creates an additional level of anxiety.  Finally, technology is changing so quickly a course of action which made sense at the start of the project can backfire at the end of the project. 

Agile and scrum attempt to solve this by using rapid iterations to build a shippable product which business professionals can then inspect and adapt. It works like a charm, but for larger projects with multiple handoffs between systems, it can create a sense of apoplexy.  Teams are on schedule but with different cadences of work.  Software code on one team does not work correctly with a different team.  Meanwhile, time continues to move forward, and deadlines made without any feedback from the people doing the work begin to slip. 

Estimates are treated like quotes because when deadlines slip executives can point to the faulty projections as an alibi for failure.  Activities such as construction and automotive repairs are easy to estimate because the rules which govern those activities are reasonably constant.  Concrete dries at a particular speed.  A repair shop can replace a tire in about an hour.  The laws of gravity have been steady for eons.  The nature of software development makes it nearly impossible for smart people to provide accurate estimates. 

Multiply this reality over numerous projects which have to work together with tight deadlines and tighter budgets you have a recipe for madness.  The software teams are groping in darkness, and the executive team is demanding some light and direction.  What can be done to break this pattern of insanity?

The first thing which needs to change is executives should understand estimates are not quotes of work.  An estimate is an educated guess at best and a cruel lie at worst.  Software working in production is the only credible sign of progress.  Based on what is working in production a leader can make more informed decisions about what to do next. 

Next leadership needs to fund cross-functional teams.  Often projects are supported, and they have a beginning, middle, and end.  When a project ends the team is disbanded and with it the knowledge to maintain or improve the system just created.  High functioning teams should stay together and given different projects.  A marketing team like this will develop logarithmic expertise and use it to defeat the competition.  If you watch Netflix, I recommend the story of Barbie and the “pink berets,” who worked in Mattel’s marketing department.  

Finally, leadership should accept software development and other complicated projects should resemble the commute to work.  Somedays the traffic is heavy and others it is light.  Construction can cause backups, and occasionally a car fire will create a gaper's delay.  Accept variability of work and try to avoid forcing unreliable estimates into schedules not grounded in reality. 

If executives and business leaders can understand these principles estimates will no longer be an alibi used to forgive failure.

Until next time.

No Estimates have a spot at the Campfire

Lots of debate around the campfire.

One of the best things about being a member of the Agile community is the smart and enthusiastic people you encounter online and in person.  It is refreshing and challenging to be around people who have a shared vision of making business faster, sustainable, and more intelligent.  The commitment to the goals of agile does not mean we are ideologically unified and dogmatic.  Like any healthy practice, we disagree with each other about basic principles, ways to spread adoption, and innovations.  The creative tension is essential.  I want to add my two cents to an on-going debate which a colleague Ryan Ripley brought to my attention from the sober and restrained convention floor of the #BetterSoftwareCon in Las Vegas. 

The #NoEstimates movement has become a very vocal camp in the agile reformation.  If you follow the debate, it is easy to see why.  The estimation process at many companies is farcical and corrupt.  Story points were created to provide the benefits of estimation without the obvious drawbacks.  The #NoEstimates crowd take this to a logical conclusion and say estimating is a waste of time and energy.

I do not feel very strongly about #NoEstimates.  What makes it interesting is it provides a different perspective to authoring software.  Neil Killick then posted a white paper this week showing some qualitative measurements which show a no estimates approach works just as well as a story point approach.  

I was skeptical but, I decided to give the article the benefit of the doubt.  Killick uses T-Shirt sizes to measure ambiguity and difficulty.  Using arithmetic and charts, he shows how he can forecast project completion.  The approach is well thought out and clear.  It is also story points dressed up to look like #NoEstimates.  It requires the product owners to spend time doing arithmetic instead of writing stories and working with customers and developers.  Personally, I struggle getting product owners to perform the basics of their duties.  Thus, using Killick’s approach may work for a different agile implementation but not for mine. 

I genuinely dislike debates which generate more heat than light.  Killick provides a good approach for a more mature agile team.  I am glad I had a chance to learn about it and will keep it in my chest of tools if I feel it worth trying.  The agile manifesto says, “Individuals and interactions over, processes and tools.” I believe that Killick’s approach is a process which might work with a particular set of individuals.  I also think that discussion of #NoEstimates is good for the agile movement.  People try out ideas, test them, and they are adopted or rejected over time.  It sounds mighty agile to me.

Until next time.