Use Cases in an Agile Project

Use cases in an agile project? You bet, use cases are perfect to augment user stories as use cases can give more context to the person reading them. Use cases can also be used by the product owner to check for user story gaps in the product back log. Writing use cases often spawns alternative use case flows as new functionality is uncovered. As these alternative flows are written by the product owner new user stories should be written so that the functionality discovered in the use cases can be added to the product backlog.

However, the timing of when use cases are written is important. Let’s say your product backlog has 50 user stories, you would not write use cases for every user story. Only the high priority user stories are candidates for use cases. Writing use cases for low priority user stories in your product backlog just adds waste and overhead to your project.

Use Cases in an Agile Project

Innovation Presentation

I saw this presentation on LinkedIn today and wanted to share.

Innovation Presentation

Failing Fast is a Good Thing

One of the benefits of switching to agile project management methodologies is the opportunity to fail fast. As a point of comparison, think about how waterfall projects work. The business requirements are assembled into a software specification. The software development team reviews the specification, creates the design and builds the software product. (I know this is an oversimplification) Some months later the software development team proudly shows the customer the software application in all its glory.

History has shown that this moment is often a moment that is less happy than expected. Some part of the software specification was not delivered as the customer wanted, or it was delivered as the customer wanted, but it’s really the wrong thing. Bottom-line, the software project or a part of the software project failed late. Ouch… It’s going to be expensive to fix…

Agile methodologies by the way they work encourage failures very early in the project. With agile project management methodologies, there are frequent software product demonstrations to the product owner. Typically at the end of each sprint / iteration the software development team demonstrates the software build to the customer. Here’s the chance to let the product owner catch parts of the software project that are off course and make corrections as needed. It is much easier and cheaper to make a change on three weeks worth of software development after a sprint than six months worth of software development at the end of a waterfall project.

Show your software to the product owner, let them find problems and fix them. It’s better to have a software project fail fast resulting in small changes than fail late and have a big mess.

Failing Fast is a Good Thing

User Story Format Thoughts

Recently I posted about a common user story format. I’m starting to see more and more discussion about this user story format and how some feel that it is too constrained. One proposal was to swap the value and actor sections. I’m trying to figure out an example of how to write this, hence my problem with this format. It does not seem natural and I really don’t see the value.

One of the great concepts of Agile is to inspect and adapt. While right now I don’t see value in changing the standard user story format, it does not mean that there won’t be a day when someone proposes a better way or writing user stories. When that day comes, I’ll inspect the new format and perhaps adapt.

User Story Format Thoughts

Communicating Agile

Here’s a surefire way to fail with your Agile implementation. Ignore the other parts of the business that are used to dealing with schedule driven projects. It’s not enough to get the project team onboard with Agile, you need to spread the word and sell Agility to as many people as you can.

Go on “Agile Tours” and give multiple presentations about your Agile Team and how you are working to reduce waste and speed the delivery of working code. Of course short presentation won’t be enough to cover Agile Methodologies in much detail, but do talk about the benefits of customer interaction, process inspection, use stories, communication, UAT and so on.

Take the time to build the trust that what you are doing is correct and is the right thing for the business. Plus in today’s economy you are focusing valuable resources on the highest priority items and will deliver results sooner, who won't want to hear about that?

Communicating Agile

Agile Thinking – Enhance Personal Productivity

It’s a tough world right now, most organizations are being asked to get more done with less. In an earlier post I talked about MoSCoW ratings as a way to prioritize user stories. MoSCoW ratings can be used to prioritize many things. Prioritizing tasks with MoSCoW ratings in a to-do is list is just one way of using Agile thinking to boost personal productivity.

When I am overwhelmed I use MoSCoW to prioritize personal tasks.

M - MUST do this task. In this context MUST is similar to Steven Covey’s Important / Urgent Quadrant. Schedule time to handle this task now.

S - SHOULD do this task. The world won’t end if it is not done today. But it’s a task that if it does not get done could lead to problems. This task should remain in your personal task backlog (to do list).

C - COULD do this task. This task is neither urgent nor important now. This task could remain in your personal task backlog (to do list) or be delegated.

W - WON'T do this task. Doing this task won’t move the project forward or provide any value. Delete this task.

We can’t add more hours in the day but we can spend the time we do have on the right things By looking applying MoSCoW ratings to tasks and responsibilities, you can make sure you are focused on the right priorities and remove waste by not spending time on needless tasks.

Agile Thinking – Enhance Personal Productivity

User Acceptance Tests - Test for Success and Build Confidence in Your Agile Team

Getting users stories from your product owner is one of many ways software requirements are conveyed to the agile team. However there is one key companion to the user story, the user acceptance test. The user acceptance test closes the cycle by providing the criteria the product owner will use the test the user story. The agile team can use both the user story and user acceptance test together to ensure they understand requirements from the product owner.

Just as when writing user stories, sometimes the product owners need help with writing user acceptance tests. It’s common to have a QA engineer assist in the process of writing user acceptance tests. I recommend using a QA engineer to make sure the software tests are clear of ambiguity.

At the end of the sprint, the agile team demonstrates the completed user stories to the product owner and validates success by executing the user acceptance tests. This software product demonstration confirms to the product owner that the software meets the requirements specified via user stories.

Running a software product demonstration and passing all the user acceptance tests is a big confidence builder for the team and the product owner.

User Story + User Acceptance Test = Clearer understanding of what the product owner wants and how the agile team can test for success.

User Acceptance Tests - Test for Success and Build Confidence in Your Agile Team

User Stories and And…

In an earlier post I talked about the three elements of a good user story, who, what, and why. The word “and” does not belong in one of these elements. If you are not familiar with the three elements of a user story, read this post “User Stories and the 3 things that make them complete” before proceeding.

Check out this user story, can you spot the potential problem?

Daytime and nighttime customers want to add products to a shopping cart and checkout so they can select and purchase products.

The example is an awkward and big user story that covers a lot of functionality. The “what” section covers multiple pieces of functionality, the word “and” is your indication that the story is too big. This user story may be so big that the functionality may not be completed in a single sprint.

The example user story needs to be two separate user stories to show a separate user goal “what” per user story.

1. As a customer I want to add products to a shopping cart so I have a container for the products I want.
2. As a customer I want to check out so I can purchase products I want.

Each of the above user stories is a viable user story that can be ranked and implanted independent of the other. So look out for the word “and” in the “what” section of a user story as a warning that the user story is too broad.

User Stories and And…

User Story Prioritization - Part 1

Prioritizing the product backlog is an important step to make sure the agile software development team is focused on the correct set of user stories. The initial product backlog can consist from a few user stories to several hundred. Trying to prioritize several hundred user stories is a huge task that can be simplified by using MoSCoW ratings.

MoSCoW ratings defined:
M - MUST have this feature – the product will fail to meet needs without this
S - SHOULD have this feature – an important feature that has an acceptable work around
C - COULD have this feature – wish list item
W - WON'T have this feature at this time – might move to Must, Could or Should in the future.

Product owners and business folks seem to understand this approach and find it easier to deal with a large product backlog by using MoSCoW ratings.

Once a user story is MoSCoW rated only the Must user stories need to be prioritized. The rest of the user stories are not MoSCoW rated high enough to warrant the effort to do a numerical prioritization. That said, MoSCoW ratings on user stories can change over time, what was once a Must can become a Could or Should and so on…

Assigning a user story a MoSCoW rating is a quick and dirty way to quickly narrow down on what is important to deliver to make the product a success.

User Story Prioritization - Part 1