What’s wrong with the user story on the card?  It seems to have everything we need: a) short title, b) a size (in this case 2), and c) a well-written story using the standard “As a … I want … so that …” format.  So what’s wrong? Nothing!  Well, almost nothing.  The user story card is a great STARTING POINT, but it is not sufficient by itself.

In coaching Agile and Scrum teams I see many of them starting out with the assumption that the user story card contains all the information they need in order to create a high quality piece of software.  Forgive me for being harsh, but how stupid is that?  Assuming a single sentence can fully describe something which might take a few days to analyze, design, code and test seems pretty ambitious.  No, let me take that back.  It’s more than pretty ambitious, it is just not possible. So I ask again, what’s wrong with this story card?

And again I’ll answer that there is nothing wrong with it, but it is a STARTING POINT.  Many people are familiar with the phrase “INVEST in good user stories” which is an easy way to remember to use the INVEST acronym for guidance when creating user stories.  I wrote a blog entry about that titled “New to agile? INVEST in good user stories“  Web searches lead people to that blog entry many times every day.  But it isn’t sufficient!  If you read agile literature for any period of time you will eventually see the phrase “A user story is an invitation to a conversation.”  This is vitally important to success!  A conversation allows more description than a single sentence.  It can clarify many aspects of the user story.  Taking this a step further we also need to be able to confirm the user story is completed.

Taking all of this together we end up with the 3 C’s of good user stories: Card, Conversation, Confirmation.  Ron Jeffries wrote about this all the way back in 2001 and his advice is still good today.  Agile and Scrum teams need to remember the card is the starting point.  It leads to a conversation where more specifics are given and negotiation (the N in INVEST) can occur.  All of that leads to confirmation in the form of tests (the T in INVEST).  A good story card will likely end up with a back side covered with results of the conversation(s) and confirmation tests.

Next time you see a user story card don’t ask yourself if you need to have a conversation about it.  Instead just assume you need to have a conversation and have it!  Go to the Product Owner or customer or customer proxy and ask to discuss the story.  Make notes for yourself.  In fact it is even better (vital in my mind) to have the conversation involve a developer, tester and product person.  I call them 3-headed conversations.  This allows everyone to be on the same page so later there is no disagreement about what was really meant by the story.  This avoids one of my least favorite conversations which happens when the tester and developer disagree about what the requirement means AFTER the code is written.

If you are using an agile lifecycle management tool rather than physical cards, record the decisions made during the conversation and any resulting confirmation tests in various fields in the tool.  You must make sure the information is captured in case someone else who was not part of the original 3-headed conversation ends up doing some work on the story.

Try using the 3 C’s and see if your results improve.  I’m sure they will.

Until next time I’ll be Making Agile a Reality^® for my clients by continuing to train and coach them to use the 3 C’s effectively.

Related posts:

1. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
2. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
3. When in Doubt Ask “How Will I Know I’ve Done That?” Tired of not knowing exactly what to create or test? Get in...

Do you want to see several different ways agile and scrum burn-down charts can lie?  If so, you are in the right place! This month I went on a burn-down chart craze and posted several blog entries about the different ways those charts can lie to us or expose us to team dysfunction.  In order, the blog entries are:

• Agile antipattern: Burndown charts that hide the truth
• Agile antipattern: Taking on large stories
• Which led to New to agile? Learn how to split stories
• Agile antipattern: Burndown “wall”
• Agile antipattern: Changing the definition of done
• Agile antipattern: Another burndown chart that lies!

The whole series had a LOT of web hits, so clearly I’ve touched a nerve.  Good luck improving your agile or scrum metrics.  Sometime next year I’ll do a series on metrics in general.  Our current state of the art for agile teams is pretty pathetic because the data can be skewed so badly (as shown by all of these blog posts).

Until next time I’ll be Making Agile a Reality^® by helping people understand the real meaning behind their agile burn down charts.

Related posts:

1. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
2. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
3. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...

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. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
2. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...
3. Agile antipatterns: Agile burn-down chart roundup post Do you want to see several different ways agile and scrum burn-down charts...

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

Question:  Which is better: a) Working nights and weekends to meet iteration commitments, or b) Admitting the commitment was too much and working normal hours regardless of the commitment?

Many people would say answer (a) is better.  I might even say that if it were a one-time anomaly, but too often it doesn’t happen just once.  The team ends up setting an artificially high velocity and are then asked to keep a similar velocity in the future.  As a result there are more and more iterations with impossible deadlines and the agile team begins to feel they are on a death march.  I even had one person in a course tell me their management had them all sign a document saying they would work nights and weekends as necessary because the company really needed the product as soon as possible.  Seriously?!?!  On an agile team???  Ouch!

99 times out of 100 my answer to the original question would be (b).  Work at a sustainable pace (no sandbagging allowed), determine a realistic velocity, and go on from there.  During the iteration retrospective an obvious discussion question would be why such an unrealistic commitment was made in the first place.  Sometimes it is just an anomaly caused by uncertainty.  That can happen occasionally and is no cause for alarm.  However, more often than not it is caused by a team trying to meet an artificial deadline and convincing themselves they can do it.  Don’t fall into this trap.  Death march projects are no fun and they may even be less fun when done in an agile way.  Seeing failure or ridiculous overload every two weeks can get to be horribly depressing!

Remember, a sustainable pace is one at which the team can perform for very long periods of time – forever basically.  I like to add the team takes pride in how much gets accomplished each iteration.  This helps prevent sandbagging because you can’t take pride in the amount completed if you sandbagged it.  Also remember sustainable doesn’t mean no vacations!  It is necessary for downtime to recharge.  Sustainable could even mean occasional overtime if the team chooses to meet their commitment in order to help them feel proud of the iteration – however this should not happen very often – if ever!

Project managers and Scrum Masters need to watch the mental and physical health of the team.  Be the conscience of the team when it comes to maintaining a sustainable pace.  Re-read that last sentence and ask yourself when the last time a project manager asked a team to reduce their hours because it wasn’t healthy!  If the pace of the team is not sustainable several undesirable effects are likely to occur:

1. Defects will increase.  Tired teams let more defects through.
2. Work output will decrease.  Tired teams do less work in more time!
3. Morale will drastically decrease.  This may lead to employee turnover at a most unfortunate time in the project.
4. The blame game will become common.  (Not our fault you didn’t say X.  I said X.  Did not.  Did so…)
5. The team starts to abandon good practices for those that “seem” faster.  Sorry, but test-driven development (TDD) is actually faster than just writing the code and throwing it over the wall to QA!

Do you have any funny stories about sustainable pace or a lack thereof?  If so, please post a comment.  I’d love to have examples to use in the future!

Until next time I’ll be monitoring teams I coach for use of a sustainable pace because there is no other way of Making Agile a Reality^® for the long term!

Related posts:

1. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
2. Agile antipattern: Changing the definition of done Ever see a burndown chart like the one to the left?  I’ve...
3. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...

Can I just be short and to the point for this one?  I hope so, because that is my intention!

Email is LOW BANDWIDTH communication

Agile teams REQUIRE HIGH BANDWIDTH communication

Do you see a problem?

Agile teams need to communicate in real-time whenever possible.  Even the agile manifesto says “individuals and iteractions over …”  In other words, one of the primary things about agile is people interacting with each other!  Email is not an interaction.  It is one way communication because we don’t know when we’ll get a response.  We don’t know IF we’ll get a response.  In fact, in almost all cases we don’t even know if the intended recipient even received the message!

Don’t fall into the trap of believing email is real-time communication.  A team relying on email will pay the price by having misunderstandings which lead to later corrections, and even worse, they will usually miss their commitments.

Until next time I’ll be continuing to tell people to use email ”ONLY when the answer isn’t important for the next 4 days” because anything less isn’t going to be 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: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
3. Agile antipattern: Treating symptoms not causes Agile teams often get to a point where they have a number...

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

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

How do we work together? Seems like a simple question, right? How wrong you could be!  For an agile team, working together is vitally important, but it is also the hardest thing to accomplish.  Why?  Because we don’t normally work together very well.  Think about the stereotypical high tech company and their sterile cubicles with “resources” working hard in isolation.  This is a far cry from the PEOPLE on an effective agile team who work in an open, collaboration friendly environment.  (In case you can’t tell, I have a pet peeve about calling people anything except people – in my opinion it is degrading to call people anything else)  But this isn’t the only problem…

Once we get the team working well together, we still have those pesky PEOPLE known as managers and executives that want to pry into every little detail.  Sorry, but that isn’t very agile, so wouldn’t it be nice if we could keep them from doing it?  What about the product people constantly changing the focus of the team on a day to day basis?  Or how about fixing the problem of the development manager constantly trying to tell the team they can do more work than is possible?  All of these things and many more come into play when we talk about the seemingly simple question “How do we work together?”

Because all of these things add up in a hurry, I encourage teams to put together a rules of engagement document to make clear some of the most basic rules and interactions.  I do this in conjunction with having the team determine their definition of what “done” means.  Both of these items are completed prior to starting the first iteration.  For maximum effectiveness have the team, managers and executives all sign the document as a sort of contract among themselves.  Having executives sign the document is extremely empowering to the team and helps them recognize they have the full support of the organization to be successful!

Feel free to use my sample Rules of Engagement document for your team.  If you make changes, please leave a comment here so I can consider making your change to the master document I use when I train teams.  If you have questions about the document either leave a comment here or email me and I’ll try to get you an answer.  This way we all can learn and improve this document for the teams that will use it in the future.

Until next time I’ll make sure teams I train use a Rules of Engagement document because it provides a lot of help in Making Agile a Reality™ for an organization.

Related posts:

1. New to agile? Work at a sustainable pace Question:  Which is better: a) Working nights and weekends to meet iteration...
2. Agile antipattern: Changing the definition of done Ever see a burndown chart like the one to the left?  I’ve...
3. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...

This is another common theme among teams just starting with agile.  It usually goes something like this:

1. The team has an unsuccessful iteration.
2. They determine all the unfinished work is testing.
3. During the retrospective they resolve to give more help to the testers so they can finish in time.
4. The next iteration is also unsuccessful.
5. The team determines once again all unfinished work is testing.
6. During the retrospective they decide the only way to have enough time for testing is to move to a longer iteration length.

Uh oh, Houston we have a problem!

This is not going to lead to success.  Think about it for just a minute.  The reasoning behind doing this is to give testers more time to test.  That sounds great in theory, but what are the developers doing during the extra time?  No, sorry, but they aren’t doing anything like sitting on their hands.  They are creating more software.  So if they are creating more software, when does it get tested?  Well, during the extra time of course!  But, but, the extra time was for testing the stuff they ALREADY created.  That’s right, we give extra time to test the stuff they created during the original iteration length, while then taking that time to create proportionally more software.  The result is pretty ugly – the testers now fall short by an amount of work which is directly proportional to the change in iteration length.  If the original iteration was 2 weeks, and the new iteration is 3 weeks, testers will fail to complete 50% more work in the new iteration length.  Bottom line, we didn’t make the problem better.

This is one of the worst antipatterns because for some reason people actually believe it should work.  Somehow they will wave a magic wand and developers will just slow down enough to let testers catch up with the new iteration length.  Sorry folks, it doesn’t work that way.  So what can you do instead?  You might try making a new rule:

There is no code except tested code

How does this help?  Well, developers can no longer say “I coded that already” for just one example.  It isn’t “coded” until it has passed testing.  This means developers get zero credit for anything which isn’t tested.  Now it is not just testers which fell short during the iteration, it is the team.  If testing is constantly falling behind and coders can’t just blame the testers, what are their options?  Well, for starters they can help the testers out.  Maybe figure out how to automate more tests.  Maybe use unit test-driven development so the software that gets tested is more solid and likely to pass the acceptance tests.  Maybe developers turn into testers in order to complete the iteration.  Believe me, the more times developers have to run tests, the more automation tools and frameworks will start to show up or become easier to use (and this is a good thing!).

This is based on the lean principle to improve the system by doing two things:  measuring UP and optimizing the whole.  I’ll almost certainly have blog posts on both of those topics in the near future, but feel free to purchase Mary and Tom Poppendieck’s books on Lean Software Development (see our books page) if you want to read about them.

Thanks for reading this entry.  If you were considering a longer iteration length I hope this post stopped you from making a big mistake!

Until next time I’ll be Making Agile a Reality™ by having my clients expose the real elephants in the room and getting rid of them.

Related posts:

1. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
2. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
3. Agile Architecture and Agile Testing – New Courses on the horizon Exciting news!  Some associates of mine are currently completing work on some...