Sunday Fun – Agile Word Search



The following words are all placed in the grid above.  Find as many as you can.


Uzility Training Friday at 2:00pm Pacific time.

Friday at 2:00pm pacific time (US), I will be doing an hour long demo of the Uzility kanban board system.  This will be about a 40 minute long free broadcast showing how to use the Uzilty system.

Here is a link to the event on Google plus.

You can RSVP or just show up to watch on Friday at 2:00pm.

Here is a list of all the Uzility topics I will be training on.



See you there.

See Also:

Kanban Boards for Non-Software Projects

I get asked all the time, can Uzility be used for non-software projects? The follow-up question is usually:  Can you change the column headings, add new columns?


The concept of Kanban boards works great in many situations, you don’t need to be building software to use a kanban board to track your progress.

Kanban Boards for Family Activities

My wife and I use a Uzility kanban board to track projects around the house. She has an idea that we need to remodel the kitchen, and I think we need to paint the family room. Over time we just establish a list of ideas that go into a column called Backlog. We then sort the backlog based on budget, available time, and time of the year. We have some pretty epic stories in the back log, like remodeling the kitchen, and some quick and easy items like Wash Windows, or rearrange the furniture in the family room.

We event have a second kanban board for family trips or activities. If my wife has an idea take the family on a ski trip to Canada, she just throws it in the list, and if I want to go fishing in August, I throw it in the list too. We sort the list, determine what we have time for, and what we can afford. If we don’t have time, or budget for a bigger trip, we just move a more affordable or shorter trip up the list to take the place of the one that is blocked.  This has worked great, and has certainly improved the overall communication around trip planning.

With uzility we can change the columns to represent different workflows, for instance on the trip planning board we have the following columns Dreamboard, Planning, Booked, and Done. It is surprising how many trips or activities we have been able to move into the done column since we started using the system.


With either of these family boards we don’t have daily stand-up meetings, but we do have occasional backlog grooming and planning were we discuss and decide on what is next and how we are going to get it done.


See Also:

Agile T-Shirt Sizing

T-shirt sizing is generally used to give more of a rough estimate in sizing, and are usually used before all the acceptance criteria are worked out on the story. The t-shirt sizing method allows the team who will be doing the work to give the product owner a wild guess of how large a task may be.

This can be useful in backlog grooming. Let’s say a product owner has 5 stories in their backlog, and that product owner doesn’t have any way to gauge the relative size between them. Additionally let’s assume that all the acceptance criteria haven’t been worked out yet either. The product owner is just looking for an idea of relatively how big tasks are.
When you are t-shirt sizing, it’s a good idea to keep it simple with only 4 sizes, Small, Medium, Large and Extra-large. Sometimes I hear comments like that’s an extra-small size, or I have even found myself saying that that user story will be at least 4 extra-larges, which isn’t the best practice. Anything that is larger than an Extra-large is simply too large to estimate, or is too epic.
You might have two very small tasks, one is to change a single misspelling in a word and you know exactly where the change is, one of those tasks that might take you 15 seconds to find and to fix. Then you may have another task that requires changing several files, and some more testing. Both of these tasks however compared to the others that you are estimating are small, and therefor are given the t-shirt size of small.

Who can t-shirt size?

Only the people who could be doing the work should be allowed to provide t-shirt size estimates. The product owners and the scrum master should not be giving t-shirt sizes. I heard a funny comment from a product owner who stated that the team estimated it as a medium, but I rewrote the story as a small. I later learned that the PO did not talk to the team to get that small estimate, he just assumed that based on his changes it would be a small. This is very dangerous, PO’s should not be allowed to estimate t-shirt sizes or points.


While you are here, don’t forget to take a look at for Agile Kanban Boards.

Product Tour Page Added to Uzility

I have just added the Product Tour Page to the Uzility site.  Today I was asked several times for screenshots and details on the product that people can see before they register to create an account in Uzility.

Here is a sample screenshot from the Product Tour Page at Uzility.



See Also:

Specifying Acceptance Criteria


I have worked with some agile product owners who when the write user stories, the like to go epic on the acceptance criteria, in fact when you read their acceptance criteria it almost looks like a complete functional specification crammed in to acceptance criteria. Other product owners simply write a user story and expect that all acceptance criteria will be discussed, or simply absorbed. One of my favorites recently was a comment heard from a developer something like “The user story says to create a modal dialog, but there are no details on what should go in the dialog”. This is a sign that the user story was poorly written and lacking the appropriate details, or perhaps that something got lost along the way.

Acceptance criteria are an important part of any user story. Without acceptance criteria you are asking the developers to freelance and create whatever they want.

When should acceptance criteria be created?

Acceptance criteria should be specified by the product owner at any point prior to sprint planning, or prior to the point in time that any estimating is being done on the story.

Let’s take the following user story as an example.

As a user I need a self-service way to change my password so that I don’t have to call support to change my password.

Acceptance criteria:

  • Verify there is a modal dialog.

Now this isn’t good enough, so let start breaking it down. This might actually occur in a backlog grooming with a more novice product owner being guided by the scrum master, developers or testers. More proficient product owners will be able to do this on their own naturally as they write user stories.

Keep in mind that a more experience team with a more experienced product owner may have certain standard acceptance criteria that they know are always being handled.

I would start by adding the user story in Uzility as shown here.


Once the user story was added, it will look something like this from the use story grid.



Now to start with the acceptance criteria.  Double click the story when it opens in edit mode, click the Acceptance tab.



You will be taken to the empty acceptance criteria page where you can click the “Add Acceptance Criteria” link to start adding criteria.  Keep in mind that there are many different formats for adding acceptance criteria.



For the different formats, some people prefer the “Given, When, Then” format, other prefer the “Verify”, and some just go free form, or a combination of the above.

For instance

  • Given the reset password dialog is shown, when the user clicks the “save” button then error messages will be shown if the passwords don’t meet the minimum password strength.
  • Verify that there are 3 input fields shown on the change password screen. The first prompts for the old password, the second prompts for the new password, and the third prompts for the new password to be entered again.

Acceptance criteria tend to sometime grow too large. For instance the verify… criteria above could be reworded as 3 or more specific criteria for instance.

  • Verify that there is an input field to enter my old password.
  • Given the user types in any of the password fields when the input is shown then the password characters should be shown with asterisks rather than the actual password.
  • Verify there is an input field for the user to enter new password.
  • Verify there is an input field for the user to verify the new password.
  • Verify if the password in the first new password fields doesn’t match the second field that an error is displayed.

This looks pretty good, but what about other areas?  Does this dialog need to have a help page created for it, if so can the help page be a different user story.  Does this dialog need to be localized so that it can be translated to different languages, this may need to be specified it the acceptance criteria.

At this point, let’s assume that we are good with the acceptance criteria, and we are going to start adding it into the system.


Enter the first acceptance criteria, click the “Save and Add Another” button, followed by all the remaining acceptance criteria.

Once the acceptance criteria has been filled out it will look something like this.


Once my favorite descriptions of a user story is “a user story is just a conversation waiting to happen”. Meaning that you do not need to write a detailed specification here, you simply need to write down enough so that the conversation can be had between the developers, testers, product owner and scrum master in order to be sure that everyone understands what is being asked for.

That conversation waiting to happen often occurs in spring planning. Let’s say the above list of acceptance criteria goes into sprint planning, the product owner presents the story, the team discusses it and asks questions, for instance someone asks “what about localization”, and the product owner replies “this doesn’t need to be localized”. An additional acceptance criteria could be added stating “For this story localization is not required”.

Depending on the experience of the team and the trust between the product owner and the team, it may be enough to not worry about documenting the acceptance criteria to not do localization, but if you want to its easy enough to add.




When you return to the user story Kanban board view, the card will show an A:6 indicating that 6 acceptance criteria have been specified for this story. You can just click on the “A:6” section and be taken directly to the acceptance criteria.


Now that the team has worked out all the details on this user story it is ready to be estimated.

See Also:

  • Point Estimating
  • User Story
  • Scrum Master
  • Product Owner
  • Uzility