About Scott Sehlhorst

Scott has been helping companies achieve Software Product Success since 1997, and started Tyner Blain in 2005. Scott is a strategy and product management consultant. He has also worked as a business analyst, technical consultant, software developer, project manager, program manager, and electro-mechanical design engineer. Scott has managed teams from 5 to 50, and delivered millions of dollars in value to his customers.

Use Cases for Iterative Development

Almost everything I’ve read about use cases focuses on describing what needs to be added to your product. Agile development says “get it working first, make it better second.” That means changing the way the software enables a user to do something they can already do. How do you manage requirements for incremental improvement?

Iterative Development and Incremental Improvement

Iterative development is the process by which you release software in iterations – small, incrementally better versions of your software. People usually think about this solely in terms of enable the most valuable capabilities first, then the next most valuable capability next.

That’s fine, when your product is new. Eventually (or quickly!) you will reach the point when the next most valuable improvement is not to add a new capability, but rather, to make an existing capability more valuable.Everything is an Upgrade

My argument in those earlier articles is that the problems you’re solving with your “new” solution are not new. Your customers are currently solving them in different ways. The relevant question for migration projects is around how much your users are changing the way they solve their problems.

[As a slight segue, failing to appreciate this distinction can lead you to a project that is based on a faulty problem statement.]

When you are delivering incremental improvements to your product, through iterative development, you are upgrading your software. You are migrating your users from their old solution to their new solution. It just so happens that you are replacing yourself, as you migrate them from the old version to the new one.

A viable strategy, that appeals to me personally, is to continuously innovate, disrupting your market, before someone else does. With this approach, you are intentionally reinventing your solution, making it difficult for someone else to out-innovate you. This is a great way to approach developing your roadmap strategically.

Your market will change. Rapidly. Do you want to react to your competitors, or keep them on their heels while you stay on the balls of your feet?

The reverberations of the “new” Twitter still haven’t settled, and many of Twitter’s competitors are on their heels – some of them only now realizing that Twitter has always been a competitor and not just “a platform.” The new Twitter doesn’t really change anything about how people use Twitter, except make it (markedly) better.Avoiding Featuritis

When is it more valuable to improve what your software already enables, versus enabling users to accomplish more with your software? Kathy Sierra introduced us to the concept of featuritis, the idea that too much is too much.

You also shouldn’t deliver a “bad” product. In fact, the ideal way to introduce a new capability is to satisfice, and not introduce the “perfect” solution in your first iteration. Make your first solution “good enough.” Part of the art is defining “good enough,” but rest assured, it is not the same as “the best you can possibly do.”

Summarizing some key elements from above demonstrates the eventual reality you will face:

Every problem* your users face is already being solved, you are just providing a better solution.

There is diminishing, and eventually negative return on adding more capabilities to your product.

Your first release of a given capability will only be “good enough.” That leaves room for improvement.

*Yes, you can pedantically define “the problem” as “the existing solution is not good enough” – but you still end up in the same place, so why bother?

Eventually, the value of improving something you’ve already released will be greater than the value of releasing something new.

Not to be confused with re-use of use cases, revisiting a use case is specifically revisiting – with the goal of improving – the implementation that is already in place within your product. This is a special case of a migration project – you’re migrating your users from your old solution to your new and improved solution.

You may be migrating to an identical process, perhaps with faster performance than your previous release was capable of. Or you may be improving the procedure (improving usability, interaction design, visual design, etc) without affecting the process. Generally, a “make it better” use case improvement effort will have no more than a minor process impact. Your users are still doing the same thing, they are just enjoying it more, or doing it more effectively.

When slicing use cases to make them fit within a single sprint, you may design them for a single user persona in the first release, knowing that you won’t meet the expectations of a different user persona until the next release. In this case, your non-functional requirements, constraints, or acceptance criteria will be different. Your use case may also be different (in the details) while appearing to be the same. This also common scenario can be addressed with the same approach.

Find that old use case (from several iterations ago) and put it back in the backlog. Remember, agile is about conversation, not artifacts. If you need to add an explanation to the use case, because your team fixates on the fact that it is “already working,” add a qualifier that it needs to be “better.” Then have a conversation, and explain how it needs to be better.Is Design Part of Implementation?

Some teams organize such that designers (both architects designing code and designers designing interfaces are being addressed here) are part of the implementation team. Other companies treat designers as stakeholders – providing guidance and input to the product managers and product owners.

When a “new design” is being requested from outside the team, include that design guidance as part of the input to the implementation team – through artifact and / or clarification.

When a “new design” is being requested of the team (the designer is part of the team), express the new acceptance criteria to the team. Note that these need to be measurable requirements if they are to be considered good requirements.Summary

There will come a time when the most valuable thing you can do is improve the user experience for a capability your product already embodies. When that time comes, use the same use case again, updated with the new constraints, non-functional requirements, and acceptance criteria.

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Recent Jobs

No job listings found.

Join Us

With 1,240,600 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.