Do you ever get so frustrated you feel like pulling your hair out?  I do (although that is NOT a picture of me to the left!).  If you look at my pictures you will see that it would be difficult for me to pull my hair out because a) there isn’t a lot of it, and b) what little there is I have cut very short.  But, enough about me, back to the issue/craziness at hand.

I last updated my blog on June 14 and here it is July 27.  That is way too long between updates, so let me start by apologizing to all of you who look forward to reading entries when I post them.  Fortunately, during the time when I haven’t been updating the blog I recognized a problem which I often see on agile teams – CRAZINESS!  Yes, sometimes things get a little crazy, or in my case recently, a LOT crazy!

My last month has been extremely busy.  Since June 14th I’ve been in San Diego (twice), Minneapolis (twice), and Philadelphia.  I’ve also sent out 8 training or coaching proposals, been on 18 conference calls, attended 3 major springboard diving meets with my son, one of my daughters had her gall bladder removed and my brother visited to do 10 days of handyman repairs around my house!  In my calendar I see that I did all those things, but it still amazes me that they all got done.  What didn’t get done?  Well, this blog for one thing!

Why is it important to point out my “lack of dedication” to the blog?  Because the answer is much more interesting than “lack of dedication.”  In fact, I love writing blog entries.  It isn’t lack of dedication at all, but rather lack of time.  I made a conscious decision to do other things rather than update the blog.  Why?  Because I work in an agile way, and when I prioritized my backlog of work it caused writing blog entries to fall near the bottom of the list.

I often see agile teams saying things like “we can’t get it all done” and then they try to do the impossible.  The result is usually ugly as they cut corners to try to make everything fit after saying it wouldn’t fit.  Instead what these teams need to remember is to continue to honor their prioritized product backlog.  Work on the important items and don’t spend any energy working on items that aren’t important.  For me, not writing this blog was a tough decision.  Writing here is a bit like therapy for me.  However, for the past 5 weeks I’ve had to put it on hold because other things were much more important.  Will I have dry spells like that again?  Probably, but when it occurs it will occur because I’ve made a decision to prioritize other things higher on my backlog.

Good agile teams need to remember that things WILL get crazy.  It is during the periods of craziness that the discipline of their approach works in their favor.  Don’t fall back into old habits when the pressure or craziness starts to get out of control.  Go back to basics and continue to work in priority order.  Working faster usually leads to more errors.  Working diligently in priority order will always outperform working “faster” on everything at once.

Until next time I’ll be Making Agile a Reality^® for my clients by continuing to prioritize my work and personal life in a way which will lead to a balance where I can deliver maximum value to everyone.

Related posts:

1. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
2. New to agile? Remember to eliminate waste When I teach any agile course I start out with the principles...
3. New to agile? Remember how to say “No” No.  Only two letters.  Very simple word.  Yet for some reason, with...

Earlier this week I posted a blog entry “Agile antipattern: Burndown charts that hide the truth” which dealt with one way a burndown chart could hide reality.  This blog entry shows another way it is possible for a burndown chart to be misleading.  The burndown chart to the left is actually pretty common, especially for teams just starting with an agile process.  In this case it looks like no progress is made for quite a period of time, then everything suddenly gets completed.  Even though this team completed all the stories in the iteration it is still an unhealthy burndown chart.

In this particular case the team had filled their iteration with “large” stories.  Notice the stepped nature of the chart.  A very healthy agile team will usually complete stories nearly every day of the iteration which leads to a chart with a downward slope, not a stepped type of line.  When I see steps like this I worry about the size of stories.  In this case there is a second factor which almost certainly points to the stories being too large: no stories are completed during the first 4 days of the iteration.  Taken together these factors almost always point to stories that are too large.

Specifically what do I mean by stories being too large?  I usually instruct teams to take their iteration length in work days and divide by 3.  The resulting number is usually a good number of days of work to average on a per story basis.  So, for a 10 working day (2 week) iteration if stories average getting completed in 3-4 days (people days, not calendar days) then they are the right size.  Because more than one person should be working on each story (you are swarming, right???) this means stories will be completed almost every day.

As the average size of a story gets larger the ability to complete a story every day is compromised.  For example, if the average story creeps up to 6 days, even with 3 people working on each story it means the average story will take 2 calendar days to complete.  In other words we’ll be completing stories every other day, not every day.  Certainly some can be completed in a day, but others will take 3 days (so the average stays the same).  This gets worse if the number of days to complete a story creeps even higher.

Why is this such a big deal?  Because larger stories tend to get harder to complete within the iteration when they are started later in the iteration.  An image I use in my courses is one of a Tetris game.  Imagine you have built up some blocks (completed stories) and there are now holes which are certain sizes.  Do you want large complicated shapes to fall, or smaller, simpler shapes?  Of course the small, simple shapes are easier to deal with just like it will be easier to deal with smaller stories.  The more complicated the shapes later in the iteration the harder it is to make them all fit and the more likely we are to fall short of our commitment.

Teams fall into this trap quite easily.  If a team has 8 members and velocity for the team is 40 it seems like the team can complete 3 stories of size 13 and 1 story of size 1.  That adds up to 40 so it should be possible.  Unfortunately, the 3 large stories make this scenario very unlikely to be successful.  If 2 people work on each story then the size 1 story gets completed very quickly, but only 6 people can work on the 3 large stories while 2 people sit around and do nothing.  Team capacity is wasted which means the stories won’t get completed.  If we say 3 people can work on a story then we still have the problem but in a different way – now we don’t have enough people to finish the large stories which are each 1/3 of the work in the iteration (we would get 2 of them done but then just have 1/3 of the iteration to get the other done).  As you can see, big stories can cause big problems.

Now that we know we have a problem, we have to solve it.  A typical planning poker deck of cards contains some very large numbers.  For this reason teams seem to think they have to use those numbers.  DON’T!  In fact, the fix I would suggest to stay away from large stories is to burn all cards higher than a 13 (maybe even 8 and higher) and never use them during planning poker.  If a story is larger than your new largest size, split it.  Oh yeah, you don’t know how to do that part.  That’s ok, read my next blog entry which will be on splitting stories!

Until next time I’ll be Making Agile a Reality^® by burning lots of planning poker cards!  I hope you do too!

Related posts:

1. New to agile? Learn how to split stories In my last blog Agile antipattern: Taking on large stories I said I would...
2. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
3. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...

Time for a short blog entry (I tend to be way too verbose!). I often see teams trying to make sure they have all of the requirements for their projects before they start doing any substantive work on the project. Unfortunately, this often leads to long delays at the front of the process which in turn causes the rest of the process to be squeezed. The Nokia Test for Agility underscores this point by having one of the questions be about specification. See this blog entry to learn more about the Nokia test and look particularly at bullet #3.

Remember a few things when you are tempted to get all of the requirements up front:

1. Requirements WILL change.  In courses I teach the average percentage of requirements which change is 50%.
2. Requirements WILL be dropped.  We almost always think we can get more done than is possible (or even desirable in many cases).  It seems the average percentage of dropped requirements is 25%.
3. New requirements WILL come up during development.  This too seems to average about 25%.

When you take all 3 of these things together you quickly realize you are fighting a losing battle by trying to “get the requirements right” up front.  Get the requirements good enough to start moving forward.  Once work starts requirements can change, be dropped or new ones can come up easily if you truly embrace the agile principle to inspect and adapt.  Keep looking for what will make the product better, not necessarily what a requirements list says from a few months ago.  This isn’t up to the developers themselves, but the product owners and others who maintain the backlog.  Build GREAT products by adapting to changing conditions.  EMBRACE change as a good thing, not as an impediment.

Until next time I’m Making Agile A Reality^® by focusing on emerging requirements over time, not trying (in vain) to get them perfect up front.

Related posts:

1. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
2. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
3. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...

Wow, has it really been more than a month since I posted something on my blog?  Ouch!  I guess I’ve been busier than I thought.  I knew it had been a while, but I thought it was 2 weeks, not a month.  For those of you who expect content from me more often, I’m sorry.  I’ll try to get back on the 2-3 times per week train.

The good news is during my time away from blogging I found lots of new topics for future posts.  In the coming weeks you find postings on different estimation techniques, how the theory of constraints can help agile implementations, using kanban, and a whole lot of other interesting stuff.  If you have a topic you want me to cover, please email me using the link near my picture.  I’ll start on the blogging train with a quick post on what to do when you are behind!

Now, to make this post somewhat useful.  I’m obviously very behind on my blogging.  My personal goal is at least 2 postings per week so at this point I am about 8-10 postings behind where I want to be.  Since I do use the agile concepts I teach, I have to be transparent and admit it.  The first step to resolving the problem is to admit there is a problem!  This is also applicable to real projects.  You can’t mitigate risk, change priorities or adjust for issues unless you know the issues exist!  Transparency is a key agile concept.

So, what is the magic bullet for step 2?  There is none.  We’ve exposed the reality, now it is time to deal with the reality but we need to be reality-based with our solution.  In my case I could sit here and type that I will suddenly spit out 10 posts this week and catch up.  But even if I could do it, it wouldn’t serve the intended purpose.  I specifically chose 2 postings per week with 3 at the upper limit because I believe it lets people digest what I write.  If I suddenly pop out 10 postings in a few days people just won’t read or absorb them.  I want this blog to be a useful source of information, not something people avoid because there is “too much” content!  Again though, the same thing happens in real-world projects.  If a team is behind schedule they can sometimes pull off heroic efforts in order to get back on track.  Unfortunately, this often points out a bottleneck somewhere in their process which means all of the work won’t be absorbed properly.  Maybe they have some specific testing resources which won’t keep up, or the necessary environments will change too quickly to be used properly, or some downstream resource will be inundated with work which can’t be done faster than a certain rate.  In other words, it is very possible for the heroic effort to simply build a queue which can’t be squeezed through the system anyway.  The best approach here is to analyze what can be done and the impact it will have.  Heroic catch-up efforts are usually ill-fated for many reasons.  In my case, I’m not going to be heroic.  I’m not on a “real” project, so I have the option of just saying the past is what it is, I’ll adjust my velocity back to being 2 postings per week, and occasionally try to get out 3.

Then there is the follow-through phase.  Now that I have made the commitment, I need to follow through.  I’m in good shape so far because this blog entry counts as 1 of my 2 entries   For a real project a team may need to commit to more accountability.  If a new goal is set and the project is adjusted to allow for success then the team still needs to deliver on the expectations.  This is why the “fix” from the previous step needed to be reality-based.  It makes no sense to commit to something which is a fantasy.

Hopefully the transparency exposed the problem early.  Being reality-based allowed for a fix to be implemented which still can be considered a success.  And the follow-through will be done appropriately by everyone on the team.  If this occurs, then behing behind isn’t necessarily a bad thing.  It is better to expose it early than expose it late when there is no chance for correction except by moving the end date.

Until next time I’ll be Making Agile a Reality™ by helping teams recognize when they are behind and helping them understand and implement realistic solutions to their problems.

No related posts.

Yesterday’s blog post dealt with how to manage scope for an agile project.  Today I have to admit it was a bit of a setup.  It was designed to set up today’s blog post which is really the important one!

See that pile of money over there to the left?  That represents a small fraction of the amount of money your organization is potentially wasting by not being able to properly manage the scope of projects.  I want to be clear this is not about project delays and overruns caused by scope creep.  I am actually writing about something completely different.  Something much more fundamental and actually fairly easy to obtain when an organization has truly embraced all that agile has to offer.  To me this is one of the most important benefits of agility, but the number of organizations doing it well is extremely small.  Warning, this is a LONG blog entry, but I think it is well worth the effort to read it!

The topic I’m writing about is the ability to manage scope and expectations properly.  The gains available by doing this are truly staggering.  If your organization was given the opportunity to increase ROI by 100% per project would someone in the organization be tasked with looking into the opportunity?  What if the ROI per project could be increased by 200%?  If the opportunity was for 500% increase in ROI per project would your organization perhaps have more than one person look into the opportunity, or would it sound too good to be true and therefore be discounted?  I know this sounds unbelievable, but the ability to achieve much, much higher ROI is very real, and it only depends on your organization’s ability to manage scope and expectations effectively.

Do I have your attention yet?  I hope so because this is really valuable information that most people just gloss over in various agile courses.  I have to admit that I didn’t cover it very well until recently.  I glossed over it mostly because I didn’t understand it very well.  Now I understand it and I’ll try to help you understand it.  The basic concept is VERY simple and can be covered with just 3 words:

More frequent releases

Yup, that’s the key.  It is much easier said than done though.  It means expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.

Let’s use a standard scenario as a starting point.  In this scenario a team of 8 people work on a project for a year with an anticipated ROI of 100% after 2 years.  In numbers this means the organization spends $1,000,000 (approximately) in 12 months to build the product and they expect to get $2,000,000 in revenue within the 12 months following release.  ROI is calculated as $profit/$invested which in this case is ($2,000,000-$1,000,000)/$1,000,000 or 100%.  Another interesting number is cash expended, which in this case exactly matches the investment since we did all of the investment prior to receiving any return.

Let’s assume that scope can be managed so the product can be delivered in two phases, each taking 6 months.  Let’s further assume each piece of the product is worth about half of the revenue value of the complete product.  In this case the team works 6 months at an investment of $500,000 to build the first piece of the product.  They then work 6 more months at an additional cost of $500,000 to complete the second half of the product.  However, after 6 months revenue starts to be brought in for the first release.  This revenue equals half of what was originally expected for a full product, so after going through some calculations we realize the amount of revenue during the first 6 months of release of the first half of the product would be $500,000 ($2,000,000 for full product for 12 months = $500,000 for half product for 6 months).  Interestingly, this exactly matches the cost for building the second half of the product, so the cash expended is actually only $500,000 for building the product vs. $1,000,000 for building the product in one step.

Now let’s look at the other numbers.  After phase 2 of the product is completed it too starts to bring in revenue.  We now have the complete product, so we can get full value of it during each time period.  In other words, during the next 12 months it will generate $2,000,000 in revenue.  This brings total revenue to $2,500,000 which means our ROI is now 300% (higher profit divided by smaller investment – $1,500,000 profit / $500,000 invested).  Remember, all we did was have two releases of approximately equal value.  Nothing else changed, but half the cash was saved and more revenue was generated.  Here is a table showing this scenario:

Time to take another step.  Let’s make the assumption we can release 4 times per year with approximately equal valued releases and the same assumptions as in the above scenarios.  Now we work 3 months at a cost of $250,000 to generate release 1.  We do the same thing every 3 months until the year is completed.  Each release generates 25% of the value of the entire release, which over a 3 month period would be $125,000.  This leads to the following table:

Now we have a situation where our cash outlay is reduced to $375,000 and our revenue has increased to $2,750,000.  This gives an ROI of 467%.

For the next scenario let’s say we can do the same 4 releases per year, but now we release higher value items first (after all, we are working from a prioritized product backlog, right???).  In this scenario let’s say release 1 is worth 40% of the total, release 2 is worth 30%, release 3 is worth 20% and release 4 is worth 10%.  Now our table is as follows:

$300,000 cash invested and $2,000,000 total profit which is now 667% ROI.

Bear with me, almost done.  For the next scenario let’s not have the team build the features worth 20% or 10% of the total product value.  They are low priority items anyway.  Doing this would generate the following table:

In this scenario we have the same cash investment of $300,000 but now we only made $1,800,000 in profit for an ROI of 600%.  Why would we want to do this?  Well, what is our team doing during those second 6 months of development?  In this scenario they are idle.  So let’s use them!  Find another project with similar parameters and have them start it 6 months earlier than whey would have otherwise.  Consider the exact same setup as in the previous scenario except we’ll be generating revenue from two different products after month 9.  In this case the table looks like:

$2,900,000 profit on an investment of $300,000 is an ROI of 967%.

Do I still have your attention?  If so, consider one final scenario:  The total cash invested in this project is only $300,000.  The organization was originally willing to commit $1,000,000 for the project.  Can you find 2 more teams and enough projects to do the same thing two more times?  If so, the original $1,000,000 investment will have been reduced to $900,000 and instead of $2,000,000 in revenue at the end of year 2 the organization could bring in $11,700,000 which is 5.85X more revenue than the original scenario and $7,700,000 more actual cash!  This equates to a 967% ROI for each of 6 products across 3 teams with 12 total releases per year.  Remember at the beginning when I said the cost of releasing would be negligible compared to the benefits?  I also mentioned 500+% increase in ROI was possible.  Do you believe me now? 

I know this was a VERY long blog entry, but I think you’ll also agree this is an important topic to understand.  To see another way of explaining it try Clarke Ching’s Rocks Into Gold presentation on Slideshare.  I hope after reading this you are as excited about the possibilities as I was when I had my “lightbulb moment” about it.  I think it is vitally important for organizations to truly understand these concepts.  I hope those of you reading this blog entry agree and will pass it on to others so they can have their “lightbulb moment” and hopefully be able to make it happen!

Oh, one last thought – if you can prioritize so the percent of value delivered by each release is even higher, then the numbers can go even higher!  For example, can a first release be worth 50% of the value?  Can a second release be worth 40%?  These may be possible in light of studies that say more than 50% of features are rarely or never used.  Said differently more than half the software in existence has no value.  If we eliminate that half, maybe we can make the earlier releases worth even more!

Until next time I’ll be Making Agile a Reality™ by helping organizations understand why managing scope in order to have more frequent releases can be so important to their bottom line!  By the way, my good friend Richard Lawrence is a person who really helped me understand this concept, so thanks Richard!

Related posts:

1. New to agile? Don’t make it too hard! OK, so this isn’t my normal type of blog entry.  I don’t...
2. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
3. Agile antipattern: Waiting for all the requirements before starting Time for a short blog entry (I tend to be way too...

The primary way I see teams release products faster is by reducing the scope of each product.  However, this can’t be done in an arbitrary fashion.  There are real business reasons for each feature request (hopefully anyway!).  Having seen teams reduce scope successfully I’ve seen three primary ways it can be done.  In order to deliver 50% faster teams can:

1. Deliver 50% fewer features
2. Deliver all features but with 50% fewer bells and whistles per feature
3. Deliver all features with a sliding scale of bells and whistles per feature

Let’s look at each of these separately to see how they work.

Deliver 50% fewer features – This one is obvious and the easiest to make work.  Because agile uses a prioritized backlog of work, a product owner can simply have the team work in priority order until enough value is delivered to make a reasonable release.  A danger here is not being aggressive enough on how much is enough.  Most product owners still go overboard and allow features to be added until the product is well past the point of being releasable.  I believe this is due to product owners being conservative by nature.  Again, this method is simple and effective, except when the sales and marketing teams have “promised” features which are further down the priority list.  If a team delivers 25 of 26 promised features the customer can be upset.  If they deliver the same 25 features when only 20 were promised they are instead praised as heros.  Be very careful with the external commitments so they can be met!

Deliver all features but with 50% fewer bells and whistles per feature – This is a bit different.  It avoids the problems of the method above because all features are being delivered.  This method is relying on studies which show 64% of features are rarely or never used (Standish Group).  In order to deliver 50% faster, 50% of each feature could be eliminated and statistically still not hit the “core” of the software which will be used most of the time.  The drawback here is each feature is treated equally and there is a likelihood too much will actually be cut from some features and not enough from other features.  Which leads to the final method…

Deliver all features with a sliding scale of bells and whistles – In this method the highest priority features are fully developed while the least important features are developed only enough to say they work properly.  The features in between the extremes have a decreasing amount of robustness for each drop in priority.  This allows for the most important features to be the most useful and the least important features to be the least useful.  This overcomes the objections of the first method because all of the features are delivered, while also overcoming the objections of the second method by delivering maximum value for the highest priority items.

I think of the three methods as slicing scope horizontally (a horizontal line through the backlog showing our last feature to be developed), vertically (a vertical line to the right of each backlog item showing how much of it will be developed compared to the maximum) or diagonally (a slanted line to the right of each backlog item showing how much will be developed compared to the maximum).  The first method is clearly the most common, but the problem of leaving off externally promised deliverables is very real.  The last method is much harder to accomplish, but it can be done.

In the last method one way to accomplish it is to create a thin slice of each feature during early iterations.  In this way the product owner knows all the features could be delivered at any point in the future if robustness didn’t count.  From that point forward the product owner can prioritize how much time and effort should be applied to each feature and create the appropriate sliding scale – even properly accounting for changing priorities if necessary.

Too often we fall into the trap of believing every part of every feature needs to be delivered.  When expectations are properly set this is rarely the case.

Until next time I’ll be Making Agile a Reality™ for my clients by helping them cut scope using the method which allows for maximum value to be delivered in the minimum amount of time.

Related posts:

1. What do you want next? The software industry today is plagued by long release cycles for important...
2. Ten Ways to Improve Your Planning Poker Results People who promote the use of Planning Poker understand some of the main...
3. Agile antipattern: Using manual tests In an agile environment manual testing is fine – except for when it...

No.  Only two letters.  Very simple word.  Yet for some reason, with the exception of when we are at “the terrible 2′s” stage of life we tend to forget how to say it!  Agile teams and organizations need to remember how to say no!  Too often agile organizations don’t get the full benefit of an agile environment because they are too busy trying to do things the old way,while using a new process which doesn’t support the old way.

In my opinion the “no” word should be used much more often at every level of the organization where agile is being embraced.  For example:

• Programs, portfolios and projects - most organizations are running too many programs, portfolios and/or projects simultaneously.  Say NO to some of them!  Concentrate on what the organization can do well, and profitably.  Monitor status and shut down underperforming projects so other projects can have additional help.  Do not throw good money after bad!
• Scope of projects – scope creep is very real under a traditional development methodology.  Why?  Because it is the only way to make sure you have any chance of hitting true market needs at release.  With agile the organization needs to be very clear about the choice between adding scope and changing the date.  If the date is flexible, add scope at will (but this is not usually the case).  If the date is important then adding scope is not possible and instead there needs to be a trade of scope (if you want X, you’ll need to drop Y).  In other words someone has to have enough courage to say NO to scope creep.
• Multi-tasking teams – too many agile organizations are matrixed or have “shared resources” (people!) which work on more than one project at a time.  This is usually done with testing teams which I think is the worst possible multi-tasking under agile.  This causes churn, which is waste.  It also means the organization has decided not to make the hard decisions about which projects are more important than others.  Again, someone needs to have the courage to say NO and create dedicated teams of PEOPLE (not resources) to complete projects rather than spinning between multiple projects.  If 3 projects each will take 1 month to complete, do them serially and get value at the end of each of months 1, 2 and 3.  Do them in parallel and get all of the value only some time after month 3 (because of churn all 3 projects will take longer than the time to do each of them serially).
• Assigning work to individuals – this is a holdover from the traditional way of developing software.  In agile the team should self-organize and self-direct which usually means pulling work in a way which is most efficient for the team, not what is nicest to put on a Gantt chart.  Say NO to assigning work and YES to pulling work when necessary!
• Creating detailed estimates – everyone should scream NO to this one.  If you want to go back to waterfall, do it.  Don’t fall into the trap of trying to do all of  the analysis up front and then believe everything is predictable.  If this worked then waterfall would be successful.  We know it isn’t, yet we keep going back to old habits trying to make things more predictable.  Please remember that PLANNING is important, but the PLAN is going to change frequently!  Don’t waste time and effort doing work which will be incorrect after an iteration or two.
• Micromanagement - if you want to kill an agile team’s productivity then try to micromanage them.  So NO to this, but YES to allowing the team to solve their own problems.

Until organizations start learning to say NO much more often there will always be too much work in progress and too many projects which won’t generate the desired returns.  We need to get out of the mindset which says stopping a project is a bad thing.  Stopping a project for the right reasons is a good thing.  It means the agile process has worked.  The failure was fast and limited and we learned from it.  We can change our approach and work on something with more potential.  Use the power of NO to stay focused and you will see significant improvement over time.

Until next time I’m going to be Making Agile a Reality™ for more organizations by helping them say NO much more often!

Related posts:

1. New to agile? Remember to eliminate waste When I teach any agile course I start out with the principles...
2. New to agile? Remember, sometimes things get crazy! Do you ever get so frustrated you feel like pulling your hair...
3. New to agile? Remember the power of automation As this blog entry is published I am teaching an agile/scrum course...

As a <user> I want <function> so that<value>.

Above is a very simple user story template.  How can something so simple be so hard to get right?  User stories make up the heart of agile development.  They are the primary input to the team.  The team takes the user stories and creates product increments based on completing those stories.  Unfortunately, getting user stories “right” is difficult to do right away.  The Product Owner (or other product facing role) needs to learn how to create user stories which meet the needs of the team.  This is a skill which can be learned over time, but I’m about to save you a bit of learning curve.

In order to create good user stories, start by remembering to INVEST in good user stories.  INVEST is an acronym which encompasses the following concepts which make up a good user story:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Let’s cover each of them with a simple explanation.

Independent:  Stories should be as independent as possible.  When thinking of independence it is often easier to think of “order independent.”  In other words, stories can be worked on in any order.  Why is this important?  It allows for true prioritization of each and every story.  When dependencies come into play it may not be possible to implement a valuable story without implementing other much less valuable stories.

Negotiable:  A story is not a contract.  A story IS an invitation to a conversation.  The story captures the essence of what is desired.  The actual result needs to be the result of collaborative negotation between the customer (or customer proxy like the Product Owner), developer and tester (at a minimum).  The goal is to meet customer needs, not develop something to the letter of the user story if doing so is insufficient!  Remember, you can always ask the magic question to help drive the conversation.

Valuable:  If a story does not have discernable value it should not be done.  Period.  Hopefully user stories are being prioritized in the backlog according to business value, so this should be obvious.  Some people say each story should be valuable to the customer or user.  I don’t like that way of thinking because business value encompasses more than just customer or user facing value.  It includes internal value which is useful for things which are normally called “non-functional requirements” or something similar.  I prefer to say the story has value to the “user” in the user story.  In this way it is clear who is to be satisfied.  Finally, remember the “so that <value>” clause of the user story.  It is there for a reason – it is the exact value we are trying to deliver by completing the story!

Estimable:  A story has to be able to be estimated or sized so it can be properly prioritized.  A value with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it.  What happens if a story can’t be estimated?  You can split the story and perhaps gain more clarity.  Sometimes splitting a story doesn’t help though.  If this situation occurs it may be necessary to do some research about the story first.  Please, please, please timebox the research!  If you do not, it will take all available time thereby depriving the product of something else which could have been done instead.

Small:  Obviously stories are small chunks of work, but how small should they be?  The answer depends on the team and the methodology being used.  I teach agile and suggest two week iterations which allow for user stories to average 3-4 days of work – TOTAL!  This includes all work to get the story to a “done” state.  Also remember not to goldplate user stories.  You should do the simplest thing that works - then stop!

Testable:  Every story needs to be testable in order to be “done.”  In fact, I like to think of testable meaning acceptance criteria can be written immediately.  Thinking this way encourages more collaboration up front, builds quality in by moving QA up in the process, and allows for easy transformation to an acceptance test-driven development (ATDD) process.  As with negotiable above, asking the magic question can help ensure the user story is testable as well.

If Product Owners and their teams work together to INVEST in good user stories the learning curve of working together will be much shorter.  INVEST encourages good habits which eliminate some of the bigger problems of user stories like dependencies, being too big, hard to test, etc.  Take the time to INVEST in good stories and see the dramatic change in how effective planning will become, as well as how productive the team will become.

Until next time I’ll be INVESTing in good user stories because doing so definitely helps in Making Agile a Reality™.

Related posts:

1. New to agile? Remember a user story is more than a card! What’s wrong with the user story on the card?  It seems to...
2. New to agile? Learn how to split stories In my last blog Agile antipattern: Taking on large stories I said I would...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

I recently saw an excellent blog post about iteration velocity.  Good reading in general, but the last paragraph really got my attention and is why I’m writing this blog post.  Do NOT compare velocities between teams!  All teams will size (or estimate) with a slightly different scale.  When I teach a course on agile I tell teams to size using points, not hours or ideal days (a blog post for another time).  This means each team determines for their situation what a size “1″ and all other sizes will be.  They are going to be different.

If you start measuring teams against each other by comparing velocities you will get what you measure.  Teams will start changing their scale so their velocity increases each iteration.  Suddenly what was a size 1 last iteration is now a size 3 (or worse!).  Don’t fall into this trap.  If teams are working hard, meeting their iteration objectives and keeping the product owner happy I don’t care if their velocity is 10 or 10,000.

Until next time I’ll continue warning managers about this practice so it won’t adversely affect their teams which are Making Agile a Reality™.

Related posts:

1. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
2. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

As an agile trainer and coach I often see new teams struggle with a simple question: “How much to do on a user story?”  A lot of people say the simplest thing that works is what should be implemented.  I agree with that wholeheartedly and even have a blog entry on how to figure out what the simplest thing is.  Unfortunately, lately I’ve found myself adding a bit to the sentence.

Do the simplest thing that works - THEN STOP!

There are developers who do the simplest thing that works and then keep going because they think the customer will want something more.  While they may be right, it isn’t their decision to make at that point.  Show what the team created at the iteration demo and see if the feedback from the demo says more should be done.  Don’t just assume it!  The extra work costs time and money, not to mention ongoing support costs if it actually goes to production.  The Product Owner needs to take all of this into account when deciding how far to take a story.

Oh, and while we’re on the topic, if you want to know how to have a great demo, read this blog entry.  It has some awesome ideas that all teams should try to follow.  The only thing I would add is to have someone other than a developer or tester be able to try the software during the demo.  Too many horror stories about how things were missed when developers went through demos too fast!

Thanks for reading this.  Until next time I’ll be helping teams in Making Agile a Reality™ by putting up a stop sign when they start trying to gold plate features!

Related posts:

1. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
2. What style of agile training works best? Have you ever been in a class or training session which is...
3. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...