Using Stories on my Personal Kanban

A colleague on Twitter asked how do I break down my stories, acceptance criteria etc?  As a reference point, "stories" refer to my use of User Stories on a task board or Kanban.  It's a method of representing requirements or scope.  In upcoming posts, I'll also write about acceptance criteria, size, blocks... Let's say you have some work that needs to be completed or delivered (scope).  Rather than the old fashioned shall statements to define the scope or requirement (system shall do this; system shall not do that), we're going to write a little self-contained story on an index card, post-it note, or something similar.  When we're done, we're going to add the story card to our kanban board.  Our user stories are written from the perspective of the user.  In the case of the personal kanban, that's me.  What you put in your user story may vary. But, for me, the stories have to be self-contained and they have to pass my "why" test.  Though I don't write it in the user story or on the card, I map work I do back to higher level goals.  If the work can't be mapped back to previously defined goals, I'm just wasting time.  Let's try not to do that.

When writing a user story, this is the format I follow

As a <type of user>, I want <goal> so <reason>.

Here it is in action

As a blogger, I want to write a blog post about user stories, so people will understand how I use them.

Now I ask myself "why". What is my predefined goal that it maps back to?

Spend more time writing, speaking, and mentoring and less time directly managing or leading projects.

So, there you have it!  Because I use both an electronic kanban and a physical one, I keep all of the details in the electronic version and use the physical one a visual reference.  It is a constant reminder to myself and others of what I am committed to do, work in progress, work that is blocked, and work recently completed.

Have any question?  Feel free to leave a comment.

Help Me Understand What I am Seeing Here

Things seemed to get a little heated in the meeting yesterday.  Upon reviewing the vendor-supplied PowerPoint deck, we noticed graphs illustrating the quantity of issues found and when the vendor planned to fix them.  So, we flipped back a few slides and noticed a table detailing the quantity of requirements that passed or failed, during the last build.  What we didn't get was something that illustrated the relationship between the two.  Since it wasn't included in the packet, we wanted an explanation. Never ask a question in an accusatory manner.  Don't be condescending.  Make sure the other party hears what you say and understands.  I started with something like this

So help me understand what I'm seeing here. I see....  ...Is that what you see?

I'm looking for the relationship between the issues found and the work you were authorized to complete.  Can you help me with this?

What was missing here was a Requirements Traceability Matrix. It would have answered everything. During this build, only work pertaining to agreed upon requirements should have been done. Only work pertaining to agreed upon requirements should have been tested. Therefore, we should have known immediately which requirements had passed and which failed.  That didn't happen.

It doesn't matter if you're using user stories or requirements.  There are documented expectations that need to be met.  User acceptance criteria should be known.

Any questions?

Meeting Acceptance Criteria Implies Customer Satisfaction

checklist

It doesn't matter if your model is Kanban, Agile, Waterfall, or RUP.  You can't close out a project or task without first identifying the Acceptance Criteria.  Acceptance criteria begins to take shape during the first moments of a project or task. If you are utilizing Kanban or Agile, everything pertaining to your deliverable should be captured on your story cards.  This includes story details and acceptance (testing) criteria.  Satisfying all acceptance criteria implies the needs of the customer have been met.

If you following Waterfall, RUP, or similar model, you would expect to identify acceptance criteria, along with scope description and project deliverables, in the project scope statement.  (These are each components of a scope baseline)

It all goes back to requirements and stakeholders' satisfaction.  Remember each requirement should add business value by linking to a business or project objective(s).

Those criteria, including performance requirements and essential conditions, must be met before project deliverables are accepted. Regardless of your model, spare yourself a lot of wasted time AND money by documenting acceptance criteria early.

Risk is Like the Five Stages of Grief

The PMBoK 4th Edition offers several risk related definitions.  I saw a trend that was very similar to the Kübler-Ross model, commonly known as the five stages of grief.  The following are a few actual risk related definitions from the PMBoK.  I hope you find them useful.

PMBoK 4th Edition

Risk - An uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives.

Risk Avoidance - A risk response planning technique for a threat that creates changes to the project management plan that are meant to either eliminate the risk or to protect the project objectives from its impact.

Risk Mitigation - A risk response planning technique associated with threats that seeks to reduce the probability of occurrence or impact of a risk to below an acceptable threshold.

Risk Tolerance - The degree, amount, or volume of risk that an organization or individual with withstand.

Risk Transference - A risk response planning technique that shifts the impact of a threat to a third party, together with ownership of the response.

Risk Acceptance - A risk response planning technique that indicates that the project team has decided not to change the project management plan to deal with a risk, or is unable to identify any other suitable response strategy.

Kübler-Ross model

1. Denial

2. Anger

3. Bargaining

4. Depression

5. Acceptance

Image Source: Pictofigo