Is the bug to the left a large bug or a small bug?  It looks HUGE to me!  Well, in reality it is probably between .5 and .75 inches long.  Not really a very big bug at all.  Why do we care? Because trying to size the fixing of software “bugs” is at least as hard as figuring out how big this bug is!

When I teach an Agile or Scrum course someone will almost always ask a question like “How do you handle bug fixes in iterations or sprints?”  When I ask “How do you want to handle them?” we get into a pretty interesting discussion.  Most people say something similar to “We should prioritize them with the user stories, size them like we do user stories and then see what fits into each iteration.”  I usually smile and ask any developers if they know ahead of time how long it will take to fix a defect.  They ALWAYS say “Sometimes.”  And THAT is the problem!

How can you actually determine the size of fixing something which is broken in an unknown way?  I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it!  If those are the only two sizes available to us how can we possibly put them into iterations effectively?

I have found one effective solution to be the use of Kanban techniques for defect fixing.  I don’t want to get into what Kanban is or isn’t and when it should or shouldn’t be used, so I’ll just lay out what I have seen be effective for a number of teams:

1. Prioritize the defect list.  This is NOT done in the context of user stories, but separately.  The list is prioritized however the Product Owner says it should be prioritized.
2. The team and Product Owner decide on how much effort (time) should be used each iteration to work on defects.  Hopefully this is not a large amount, but it might be for teams which have large numbers of defects in a legacy system.
3. The team determines when the defect fixing time occurs and how they do it. Most effective is to put a gate or two in place on the defects.  For example, gate 1 may say the developer needs to know within 2 hours if the defect is going to take more than a day to fix.  If so, then put it off until a discussion can take place with the Product Owner.  Gate 2 may be after a day if the defect is not fixed perhaps another discussion needs to take place.  However the gates are set up (if they are)  the defects are worked in priority order.
4. Limit the number of bug fixes being worked at one time to a very small number.  If you don’t do this you will have each developer working on at least one defect and run the serious risk of none of them getting fixed before the iteration or sprint ends!

This 3 step approach allows the team to work on defects in priority order while allowing a set amount of time to be spent on the defects.  The amount of time spent can be changed as needed to address the business needs of the organization at any point in time.

The downside of this is no one can tell a stakeholder something like “that bug will be fixed by date X” or “we’ll knock out X bugs this iteration.”  Saying anything like that is a lie anyway, so this shouldn’t be a big issue.  I say these statements are lies under the assumption the defects are non-trivial.

How else have you managed a defect backlog that has been effective?  I’d love to have more proven techniques for people to experiment with!

Until next time my clients will be Making Agile a Reality^® by using sizing only when appropriate!

Related posts:

1. Testing to find defects is waste Have you ever heard someone say that testing to find defects is...
2. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
3. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...

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

I’m going to be spending a lot of time in 2010 writing blog entries.  Remember, I’ve committed to trying to write 4 blog entries per week, but in order to continue to grow in my abilities as a trainer and coach I need to continue to expand my knowledge.  The internet is great for things like this, especially now that blogging is done by more people.  I can now find niche content which fits my needs and just focus on those sites.  I’ve decided to share some of the blogs which will be on the top of my “must read” list.

I’ve broken the list into several sections, so feel free to peruse the ones where you have the most interest.  I’ve also made sure all of the listed blogs are in my sidebar blogroll.  Some of you may be wondering why there are more blogs listed in the sidebar than in this entry?  I do follow all of the blogs in the blogroll (and more), but some of them don’t make it to the “must read” list and instead reside on the “read whenever I have time” list.  There is nothing wrong with the second list.  It just acts more like Twitter – if I miss some entries I’m not going to be overly concerned.  Oh, and I’ve not put blogs from agile tool companies.  This isn’t to say those aren’t good, because they are, just there is usually so much data I can’t keep up with it all the time!

Agile Cooperative Blogs

Richard Lawrence – Lately Richard has been working on Cuke4Nuke – very interesting!
Powers of Two - Rob Myers doesn’t blog a lot, but when he does it is usually good stuff
Techniques of Design – David Bernstein on agile code quality, design and architecture

Other Agile Blogs

Succeeding with Agile – Mike Cohn’s blog – ‘nuf said!
Leading Agile – Mike Cottmeyer writes from the heart
Ruminations – Elisabeth Hendrickson on agile testing and more

Scrum Blog

Scrum Log – Jeff Sutherland, co-creator of Scrum – ‘nuf said!

Lean Blogs

David Anderson – Lean Channel – David is a leading expert
Scaling Software Agility – Dean Leffingwell wrote the book

Kanban Blogs

David Anderson – Kanban Channel – David is also an expert here!
Limited WIP Society – Lots of different authors

Little Bit of Everything Blogs

Bridging the Gap – Laura Brandenburg on business analysis
Managing Product Development – Johanna Rothman from an agile perspective

I like to read the blogs listed here because I find them entertaining, challenging, thought provoking, or simply interesting.  I know we all have different favorites, so if you don’t see your favorite blog listed here or in my sidebar, please feel free to leave a comment.  Only one rule, don’t promote your own blog.  It IS perfectly fine if you find someone else to shill for you though   I just don’t want too much blatant self-promotion going on.  If it isn’t listed here or in the blogroll there is a good chance it is in my “big list” but due to space limitations it didn’t make the cut.  If it gets recommended by others I may just change my mind!

Until next time I’ll be working to become better at Making Agile a Reality^® by learning from the wisdom of others.

Related posts:

1. New to agile? Get focused with a vision Bear with me on this blog entry.  It takes a bit of...

In my last post I gave you insight into how I do my work as an agile team of 1.  What I didn’t mention is I am highly mobile.  I travel a lot to other cities and even when I’m in my normal city I have meetings all over the place.  How do you remain agile if you don’t always have access to the same environment?  Let me tell you, it isn’t very easy.  It requires lots of help from tools which work without me having to think about making them work.  It also requires forethought on how your normal workflow will occur.  Finally, it requires knowledge about how certain tools function so they can be set up properly.

To start let me tell you my setup.  I have 3 primary computers.  The first is a desktop which is strictly for home use, not business use.  It contains all personal information, personal email accounts, personal Quicken and things like that.  The second is a 17″ Dell laptop which is my primary business computer.  However, it rarely leaves my desk any more because I now also have a small 10″ MSI Wind netbook which travels wherever I travel.  They are all sufficiently powerful for what they need to accomplish.  For the purposes of this blog entry I’m going to leave out the home computer because it simply shares an external monitor with the 17″ laptop.  Everything else about it is totally separate from my work as an agile team of 1.

I also have some other equipment which I find invaluable.  I have a networked drive which is 1TB in size.  I also have an 8GB USB stick which is also a USB splitter (it takes 1 USB port and turns it into 2 while also being an 8GB USB drive).  I also carry a USB cable which plugs into my phone for both charging and transferring data.  I also don’t go anywhere without my smartphone which runs Windows Mobile.  These extra devices are a necessary part of my overall strategy of being agile while being highly mobile.  They are probably overkill, but I am an engineer at heart so I’d rather have redundancy than have an unrecoverable issue.

Finally I have multiple email accounts “in the cloud” including a Gmail account and a Hotmail account.  For my company email I use an Exchange Server that allows Direct Push as well as Outlook Web Access.  I have access to Google Docs, Google Wave, Twitter and a host of other things which aren’t important right now.  I only mention these because they do come into play on occasion.

Wow, now that I look at it I am seeing quite a list!  No problem though, everything has a purpose and none of it is even hard to set up.  Costly maybe, but not hard

On my laptops I basically use only a couple of indispensible tools: Microsoft Office Ultimate (why in a moment) and a browser.  Everything else doesn’t matter a lot.

My normal workflow

In the first paragraph I said you needed to know your normal workflow in order to determine how to configure a system which would work for your usage patterns.  In my case I do some things like email, reading group mail and reading other blogs quite a bit.  I also edit my blog, maintain my calendar, browse the web, Twitter and edit documents almost every day.  Those are all things I do whether I am in my office or on the road.  When I am in my office I also may be doing things like maintaining the company financials.  When I am on the road I am often giving presentations of some sort or creating a document as a result of my work.

My solution

They keys to my solution are Microsoft Exchange Server, Microsoft Groove, an automatic backup program, and the Windows Task Scheduler.  These 4 items do all of the dirty work behind the scenes so I can just use one of my computers and know I’m in good shape no matter what  happens.

• Microsoft Exchange Server – This is important because it keeps a copy of my important correspondence, my task list, my calendar and my contacts “in the cloud.”  I can access it from anywhere via the web and Outlook Web Access.  I can access it from my phone, and more importantly, the changes are always PUSHED to my phone in near realtime so I don’t have to think about it.  I use many folders to store correspondence by type and Exchange keeps those folders available to me whenever I need them.  Both computers are kept in sync as long as they are online and have Outlook running.  I know people are starting to like the Google solutions (Gmail, calendar, etc.) but I just can’t get the same level of comfort with those as I do with Exchange.  It’s probably because I’m an old fogey.
• Microsoft Groove – THIS is why I purchase Office Ultimate edition.  It is the only edition that includes Groove.  Groove keeps a “workspace” in sync between 2 or more computers.  Without any human intervention!  It is a marvelous program – at least for me.  I have an “AgileForAll” workspace on both of my laptops.  As long as a laptop is online it will automatically sync all files in the workspace to the latest version.  If the latest version is on the laptop and it is different from what is available to other computers (in other words I edited a file in the workspace while offline) it will push those changes into the cloud for later downloading by other computers set to sync.  This requires ZERO work on my part.  I don’t even think about it.  If I edit a file and save it, as long as I am online and the other laptop is also online, the changes will just show up on the other machine, and usually very quickly (less than a few minutes).  My workspace has quite a few separate directories which lets me keep everything organized.  I even have a backup of my website in the workspace so I can change it easily from either machine!
• Automatic backup program – It doesn’t really matter what program you use as long as you can do full and incremental backups.  I back everything up each night to the networked drive.  When I’m on the road that laptopt doesn’t get backed up, but it syncs the important files to the othe laptop which IS backed up so I’m still protected.  I have things arranged so I can go back at least 30 days and not lose anything.
• Windows Task Scheduler – This one isn’t all that important, but it helps me sleep at night.  During the night if a thumb drive with a particular file is available then the laptop will make a raw copy of the Documents directory (which includes the Groove workspace), as well as some other important files like Outlook files and Quickbooks files.  This is not a regular backup which is usually compacted.  This is just a raw copy to the USB stick.  This means I have all of my work on the USB stick, on the network and in the cloud in case anything happens.  I use a couple of different USB sticks and keep one offsite.

This setup allows me to use either laptop at any time in any location and have access to all of my latest stuff including documents, presentations, calendar, contacts, task list and email.

This works for me a lot better than trying to use a remote desktop application, but just in case, I have GoToMyPC installed on all my systems too!  There is probably a lot of overkill in this system, but it isn’t anything I have to think about therefore it isn’t causing me to have waste in what I do.  Once it is set up it all just works.

There are some shortcomings though.  I don’t currently use a versioning system of any sort.  I tried to use both SVN and git but neither did quite what I wanted.  They required me to THINK about keeping things in sync and I didn’t want to do it at the time.  git also didn’t work because it made my system very unstable.  It crashed twice within an hour of installing git, even though I wasn’t using the program!  SVN works well and doesn’t crash my system, but I’m not quite sure yet how I want to use it.  I may at some point have an SVN repository in the cloud and do some automatic check-in, but I haven’t decided that yet.

This is a long entry about a problem most people don’t have, but if you do have this issue, perhaps this will help!  By the way, this works just as well for keeping a desktop/laptop combination in sync, or a work/home computer, etc.  It just happens that those problems are baby versions of a highly mobile agile team of 1

Until next time I’ll be Making Agile a Reality^® for myself by not thinking too hard about mobility because I’ve already solved those problems!

Related posts:

1. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...
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 pondering: Why use an agile approach? The theme of the blog this month is “Getting a Fresh Start.” ...

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

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

Bear with me on this blog entry.  It takes a bit of setup until I get to the main point.

Lately I’ve been doing a lot of reading about blogging and how to make a blog better. I didn’t get very far when I was hit with the opening question which is

“Why do I blog?”

When I first read the question I thought how silly it seemed. Why start with such a simple question. Obviously I blog because… Uh, why do I blog?

OK, it wasn’t quite as simple as it seemed.  So being a diligent person and really wanting to improve my blog and my blogging skills I decided to try and answer the question.  One of the articles gave a short list of reasons other people wrote blogs.  Surely the answer would be there.  Wrong!  Ok, try again with another list.  Nope, no luck there either.  I was starting to think maybe I shouldn’t blog at all if the main reasons people blog didn’t apply to me.  Then I realized, that was very close to my answer.  I was struggling to make sense of things, which led me to say…

I blog to help struggling software development teams in
Making Agile a Reality™.

This bottom line really goes back to my blog entry about not settling for mediocrity.  I want to help teams improve!   These teams may be using a traditional approach to software development and need to know there is something else which may help them.  A team may be looking for reasons to use an agile approach and find one of my blog entries.  They may be using an agile approach and want to improve.  A project manager may be wondering how to best help their agile team.  Lots of different scenarios all boiling down to the same thing – there is pain, and one of my blog entries may be a pain reliever.  Sometimes I hit the mark and get a lot of hits on a blog entry.  That’s when I know I struck a nerve.  Other times blog entries are barely read (like I presume this one will be).  That’s ok now that I know my mission.  If I help even one person or team feel like they can be more successful, then it has been a success!

If helping struggling software development teams is the mission behind my blogging, how does this blog entry fit in?  Determining a mission statement for my blogging is very analagous to having a vision for a product - it focuses the effort on what is truly important and valuable.  Being able to prioritize my list of ideas for blog entries based on my blogging mission will help me be much more productive.  I believe the gain in productivity will allow me to create content which is more valuable.  I’m looking forward to it.  Having focus on agile projects allows potential changes to be evaluated against the focus which often shows the change to be immediately out of scope.  Applying the principle to eliminate waste implies the change would simply be put on the product backlog for a potential future release.  Much less effort than trying to prioritize it without a vision.  Too often that results in trying to determine how it DOES fit rather than how it DOES NOT fit which leads to expanded scope and missed dates.

For your team ask the question “Why do we do that?” for things you do each iteration or release – you may be surprised at the results!  You might also want to do a small exercise which is usually very illuminating: have everyone on the team write a vision statement for the product.  I like the format from “Crossing the Chasm” by Geoffrey Moore:

FOR <target customer>
WHO <statement of need>
THE <product> IS A <product category>
THAT <key benefit>.
UNLIKE <primary competitor>
OUR PRODUCT <further differentiation>.

I have done this exercise many times over the past 12 months.  It is rare when more than 2-3 team members come up with similar visions.  Gain focus – have a vision!

Until next time I’ll be Making Agile a Reality™ for myself by looking for other areas where I need to apply focus and asking the question “Why do I do that?”

Related posts:

1. When in Doubt Ask “How Will I Know I’ve Done That?” Tired of not knowing exactly what to create or test? Get in...
2. New to Agile? Use a Rules of Engagement document. How do we work together? Seems like a simple question, right? How...
3. What do you want next? The software industry today is plagued by long release cycles for important...

James Shore recently changed the entire focus of his company. This blog entry gives his reasons why. The blog post really struck a chord with me because I often use the phrase “To me mediocre is not acceptable.” Now I’ve found someone that agrees with me!  To me there is nothing worse than seeing a team not reaching their full potential because they are unable to see the problems they are causing themselves.  In fact, some teams even laugh about it when it is pointed out to them!  Grrr, don’t let that happen to you.  Read on for some things to watch out for.

There are many ways mediocrity can appear and seem harmless. If you are new to agile, here are a few that you need to be careful about.

• Daily stand-up meetings taking more than 15 minutes
• Team members being late to meetings
• “Just a little” testing not completed within the iteration
• Not inviting users, customers or stakeholders to iteration demos
• A retrospective where no action items for improvement are created
• Decreasing the committed scope of an iteration
• Team members not working on stories in priority order
• Boring daily stand-up, retrospective or planning meetings
• Defects regularly being found after an iteration is completed
• Iteration planning taking forever because the Product Owner is not ready
• Lack of release planning
• The big picture for the project is never made clear

There are many more things which could become commonplace and accepted.

DO NOT ALLOW IT TO HAPPEN!

Once you allow mediocrity (or worse!) to occur once, it suddenly becomes accepted behavior.  Do yourself and your team a favor and insist mediocrity is not acceptable!

Until next time I’ll be standing my ground on this issue while Making Agile a Reality™ for my clients.

Related posts:

1. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
2. Agile antipattern: Doing Agile! I spent the past week in Orlando, Florida  at the Agile Development...
3. New to agile? Give thanks! Here in the United States we will be celebrating the Thanksgiving holiday...