In my last blog Agile antipattern: Taking on large stories I said I would give you some tips on how to split stories.  First though, it is important to understand WHY splitting a story well can be helpful.  It is about much more than just making smaller stories.  In fact, making smaller stories may be the least important part of splitting stories.  The most important aspect of splitting user stories is to help make sure the team can be successful.  However, that statement has a lot implied in it.  We need to dig a lot deeper to expose the real reasons for splitting user stories and not just do it as a good practice (we must BE agile vs. DOING agile).  Not that it isn’t a good practice, just that there are more reasons for doing it!

How can the team be more successful by splitting large stories?  Well, my last blog entry on taking on large stories makes it clear one advantage is stories will fit better into an iteration when they are smaller.  But I said making them smaller was not very important, so there must be more to this than meets the eye, right?  Yes, there is!  Below is a list of 10 reasons why splitting large user stories will help teams be more successful.

1. It may be possible to split a story so some of the work on the original story doesn’t have to be done.  Ding, ding!  Huge productivity improvement!  Lean principle alert – eliminate waste!  This reason is good in some many ways you can’t even begin to count them.  Any time work can be eliminated without affecting the overall value of the product it is a good thing.  Oh, and if after splitting the story we see we don’t need to do any of it, well that’s just AWESOME!
2. Stories can be split to expose more personas.  Sometimes teams see a story as large because there are many different types of personas which must be taken into account.  The story becomes easier to deal with, and we gain clarity, when we see the personas split out separately.
3. Stories can be split to help expose risk.  We may have user stories which have elements of risk in them.  If we can split the user story to isolate the risk we may be able to avoid the risk altogether.
4. It may be possible to split a story to ease a transition.  When we upgrade existing functionality we often give users a bit of a shock.  Sometimes we can split stories to give a smaller shock up front and postpone other work until a later release.
5. A split story may be able to have more people work on it at once (swarming).  If a story is large and requires primarily one type of expertise we tend to let a single person do all of that type of work.  However, a split story may enable others to chip in because some portions of the large chunk of work can be handled by people with less expertise.
6. Splitting a story may give us more visibility into its true size.  I have seen many teams split a size 13 story into 3 pieces and end up with 3 stories each of size 8!  In fact it isn’t even that uncommon.  When we have an upper bound on our story size we tend to use that size for anything “big.”  This leads to large under-estimating for truly large stories.
7. A story split may allow us to use a different quality standard for the new stories.  A simple example in a reporting system may be two of the same type of report, but one is run hourly and one is run yearly.  The hourly report may need higher quality than the one run yearly.  This may be a bad example, but I think it gets the concept across.
8. When a story is split correctly it can help with testing.  Some portions of the story may require full end-to-end testing, while other portions may be able to be tested in a mock environment.
9. A split story may isolate performance factors.  One portion of the original story may affect performance while another does not.  This may affect prioritization as well as performance testing time.
10. Of course, splitting stories may just make the original story be in more digestible chunks so they fit better into iterations.

Those are all good reasons for splitting user stories, but I haven’t really told you how to do it.  That’s because I don’t have to.  My good friend and fellow founder of the Agile Cooperative, Richard Lawrence, recently had a blog entry on Patterns for Splitting User Stories.  He explains it much better than I ever could!  In fact, he explains it so well that Dean Leffingwell is going to be using Richard’s work in his next book.  High praise indeed.

Until next time keep Making Agile a Reality^® by splitting those large stories!

Related posts:

1. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...
2. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
3. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...

In Scrum one of the named roles is that of Product Owner.  Some people have taken to referring to this position as the “single wringable neck” on a Scrum team.  This is because the Product Owner is ultimately responsible for the prioritized product backlog which the team uses as their to-do list to build the product.  If the Product Owner does a poor job then the resulting product will not meet customer needs.  That scenario leads people to believe the Product Owner should be held accoutable for the failure.

To me this is very short-sighted.  The Product Owner has a LOT to do without having this additional burden placed upon them.  Because I want to keep this blog entry short I will give 5 reasons why the “single wringable neck” concept has to be left behind:

1. Product Owner’s normally do not have sufficient training to do the job well.  We often here of Certified Scrum Masters (CSM), but we don’t hear about Certified Scrum Product Owners (CSPO) nearly as much.  This is a shame.  If they are the single wringable neck, why not give them a fighting chance by giving them some training specific to their position.  I don’t care if the training is a certified training or not, so long as it is good, solid training.  A few months ago we had our Agile Product Management Boot Camp which is a great way to get this training.
2. Some organizations isolate Product Owners in a way which does not allow them to interact with customers properly.  I’ve actually heard sales people say “We can’t have the product person talking to our customers – it would just confuse the customer.”  When I heard this I think my reply was “In other words they might tell the customer the hard truths?”  You can guess how the conversation went from there.
3. Many organizations expect too much from their Product Owners.  Product Owners need to interact with the team and customers on a regular basis.  They also need to be doing other forms of market research.  They may need to attend trade shows.  They may be involved in Change Control Board meetings.  They may prioritize defect lists.  They may be helping the marketing department develop materials.  They may be creating nice charts and fancy reports for executives about how products are expected to perform.  They may…   The list can go on forever.  Please make sure your Product Owners have time for what is truly important.  Find other ways to accomplish the tangential items.
4. Product Owners don’t get to understand lost sales.  If you are trying to create a product to grow your market share then finding out why you lose sales is CRUCIAL!  Lost sales is a huge potential source of product ideas.  Talking to current customers may help you maintain your market share, but it isn’t guaranteed to grow it.
5. Product Owners ultimately report to someone else and that someone else sometimes makes inappropriate decisions.  Sorry to be so blunt, but this occurs more often than anyone wants to admit.  How can a Product Owner be held accountable if someone else ultimately pulls the strings?  Worse yet, the person in charge often doesn’t admit the errors were their fault.  This all falls in the category of sad but true.

As you can see, I don’t agree with the single wringable neck concept.  I believe a team creates products and all members of the team contribute.  A Product Owner may ultimately be one of the major contributing factors to failure, but it is rarely the only one.

Until next time I’m going to be Making Agile a Reality^® by helping teams get effective training and coaching for all team members including Product Owners rather than concentrating on just one or two team members bringing information back to the team.

Related posts:

1. New to agile? Give thanks! Here in the United States we will be celebrating the Thanksgiving holiday...
2. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
3. What do you want next? The software industry today is plagued by long release cycles for important...

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. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...
2. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...
3. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...

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? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
2. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
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. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
3. How to make a LOT more money using agile Yesterday’s blog post dealt with how to manage scope for an agile...

I was just working on some Powerpoint slides for our Agile Product Management Boot Camp coming up on March 9 and 10 and I realized I should post a blog entry about the point the slides are making.  Actually, I’m trying to make two points with the slides.  The first point is we tend to work in organizations where the phrase “everything is priority 1″ is common.  The second point is my personal distaste for using the phrase “prioritized product backlog.”  I’ll cover each of these points separately.I’ll start with the “everything is priority #1″ problem, since that is the title of this blog entry.  Let’s be very clear THIS CANNOT BE ALLOWED!!!  There are many blog posts on the web such as the ones here and here.  I like what the first of those links says about how to explain why everything can’t be priority 1 – we can’t build it all at once!  I usually approach this with product managers/product owners/stakeholders by asking them what they want if they can only get one thing.  They quickly say one thing is useless they need it all.  To which I reply, I know, but I want to make sure we have the most important item built first so we can learn from it and make changes to other items based on what we learn.  I’d like to rank all of the items 1 to whatever, with no ties, so we can always be working on the next most important item and be able to learn from it as well as all the other items which were more important.  This way we will make sure the most important items are in the release and meet expectations.

Which leads into my second point about the phrase “prioritized product backlog.”  If you simply say the words, nearly everyone in the software industry will say  they already do that.  Why are they saying this when a casual observer can tell it isn’t true?  It is because we have overloaded the word prioritization.  Most software people think having a list of 100 items which has the top 97 as priority 1, the next 3 as priority 2 and no priority 3 items is a prioritized backlog.  Sorry folks, but that is a useless list.  We really need a RANKED backlog, where the rankings go from 1-N and there are no ties.  Then we use the list by making sure we work on the next item in the ranking, not just work on some random thing which seems interesting.

We simply have to keep these two issues in mind when we are dealing with the product backlog or we will not be successful.

So, what do the two slides look like?  Here they are:

This is the first post in the “Agile Antipattern” category.  I anticipate having a few more over time.

Until next time, let me know what you think so together we can be working toward Making Agile a Reality™.

Related posts:

1. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
2. Agile antipattern: Sizing or estimating bug fixes Is the bug to the left a large bug or a small...
3. Agile antipattern: Waiting for all the requirements before starting Time for a short blog entry (I tend to be way too...

Tired of not knowing exactly what to create or test? Get in the habit of asking the magic question “How will I know I’ve done that?” In other words, ask the Product Owner (or whatever person you have filling that role on your team) to express some acceptance criteria!  Asking this question will make miserable days seem bright and sunny!  Well, ok, maybe not that, but asking this question will brighten your mood.  There are at least three good reasons why asking this question is important.

First, the answer clears up uncertainty.  As I mentioned in my blog post Bob-ism #1 – the good developer it is very easy for developers to build the wrong product if they aren’t careful.  Being careful means uncertainty on the desired functionality needs to be cleared up as early as possible.  There is no such thing as the perfect Product Owner who creates 100% unambiguous stories that never generate questions.  This is impossible because it absolutely should not happen.  The concept behind stories is they are an invitation to a conversation. The conversation should start with “How will I know I’ve done that?”  Members of agile teams need to recognize the necessity of clearing up uncertainty, and Product Owner’s need to understand the necessity of making time available to help.

Second, the answer gives acceptance criteria. Acceptance criteria are useful to every person who deals with a user story.  Developers know how the code will be tested. Testers have a basis for knowing what tests to create.  Wouldn’t it be nice if acceptance criteria could directly be translated into automated acceptance tests?  Well, we have a class on Real World Agile Testing with Fit and FitNesse coming up.  The class is basically to teach how to do that!  Even if you don’t take the class, look at Fit or FitNesse as potential ways to translate between spoken language and automated tests.  But all of this is based on knowing what the acceptance criteria should be, and the answer to the question “How will I know I’ve done that?” gives the criteria.

Finally, asking the question fosters collaboration.  Remember, a user story is an invitation to a conversation.  By asking “How will I know I’ve done that?” you have accepted the invitation.  Imagine if all teams had developers, testers and Product Owners collaborating up front on stories and all being in agreement on what “done” would look like - all before a line of code was written.  For those of us who have seen this in action it is truly amazing.  Teams become hyper-productive.  Features match customer wants and needs much more accurately.  Quality improves dramatically.  Morale on the team improves.  All of these are downstream effects of effective and meaningful collaboration.

Let me close this post with a couple of very important caveats:

• Don’t collaborate in a vaccuum.  If one person needs to ask this question, there are likely others also needing to know the answer.  Make sure you have the proper people as part of the conversation.  This usually means developer, tester and Product Owner are all involved.
• Capture the answer!  This seems so silly to have to say, but it is quite common for people to have a conversation and not record the results anywhere.  This conversation affects the user story, so capture the answer in a place people will know to look.  The answer is acceptance criteria.  It may even clarify some wording in the story itself.  Whatever it is affects the story, so save it appropriately.  Remember, knowledge in your head is lost to the rest of the team – so what happens when you aren’t available???

My user story today was “My readers want a new blog entry so that they can be more agile.”  I asked myself the question “How will I know I’ve done that?”  The answer was “I’ll know I’ve done that when I have a published blog entry my users can access which gives them a useful agile tip.”  So the acceptance criteria are:

• blog entry published
• users can access
• contains a useful tip

I tested the first two and they work.  Did I accomplish the mission for the 3rd bullet point?  I certainly hope so.  If not, let me know!

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? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
3. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...

The software industry today is plagued by long release cycles for important products. That is one of the many reasons why companies are going to agile methodologies. In doing so companies hope to deliver software on a more regular basis. They feel this will make for happier customers. Of course I’m not going to say they are wrong, but it goes far beyond the fact that they get more frequent deliveries of software.

I believe one of the biggest differences comes from how the “feature bus” is different in an agile environment. When using non-agile methods we still try to ask the customer a question like “What would you like to see in our product?” Our problem is that our customers recognize how software development occurs and what they hear is something like “The feature bus is here, so I better pile in as many things as I can think of because this is the only stop it makes this year!” The worst part about this is the recognition that what they hear is probably true. It leads to conversations like this:

Us: What would you like to see in our product?
Customer: (lists 100 items including things they only peripherally think they may need some day)
Us: Wow, that’s a big list! Let’s be real here. What do you really need?
Customer: OK, you’re right, those last 3 items out of the 100 I don’t need.
Us: I don’t think you understood. What do you REALLY need?
Customer: Ok, throw out #96 as well.
Us: Let’s try a different approach. Which items are most important to you?
Customer: Oh, in that case, only the first 90 are really priority 1, the others are priority 2.

As you can see, the conversation is rather fruitless. With good reason. After all, we don’t usually deliver products frequently enough for our customers so we have trained them to behave this way.

Agile changes the model dramatically. With frequent software deliveries and potentially even more frequent iteration demos (you do invite customers to iteration demos don’t you???) the customer gets used to seeing things in a much shorter timeframe. They understand that they don’t have to pile on the useless items where they don’t have much clarity yet. If they concentrate on important things they will get those quickly. The world changes when we can ask the initial question as “What do you want next?” Instead of an open-ended question asking the customer to dump everything on us, we are asking a slightly closed question where the answer may be only a few items. Plus we get a bonus out of this – how hard is it to prioritize a few items vs. prioritizing 100 items?

When we change the frequency of the feature bus we will change the behavior of our customers. Most surveys say the #1 or #2 most critical project success factor is having early and frequent interaction with the customer. This is a great agile practice that often isn’t used to full effectiveness. Start inviting customers to demos and asking them what they would like to see next. You will be astounded at how quickly their trust builds and how quickly you start making better products because of it!

So, what would you like to see next in this blog?

Related posts:

1. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
2. Agile pondering: Is it agile to have a “single wringable neck?” In Scrum one of the named roles is that of Product Owner. ...
3. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...