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

User Stories and the 3 things that make them complete

A really good user story will have three things to make them useful and complete

• Who
• What
• Why
  

I’ve seen so many user stories that have the Who and What nailed, but they miss the Why. Adding the Why seems to be the hardest part, but it’s so useful for prioritization and for stakeholder understanding.


So what are these user story elements?

• Who = the primary actor. The Who can be generic like customer, user or specific such as specialized user of a system. The Who can also be a non user such as a server; I’ll give an example later.
• What = the action the primary actor wants to take.
• Why = the value or the reason the primary actor wants to do the action.
  

When writing user stories I’ll use standard phrases to ensure the completeness of the user stories

1. “As a” to identify the Who
2. “I want to” to identify the What
3. “So that” to identify the Why
   

So let’s write a few user stories as examples

1. As a customer (who) I want to add items to a shopping cart (what) so that I can purchase them (why)
2. As a server (who) I want to receive well formed xml (what) so that I can process XML without errors (why)

As I write this I found some proposals to switch the Who, What Why to Why, Who, What to provide the business value up front. It’s an interesting idea to try when you write your user stories.

User Stories and the 3 things that make them complete