Defining The Qualified User Story

User Story

Regardless of the client I work with, the teams seem to initially struggle with understanding how big (or small) a User Story is, relative to Epics, Features, and Tasks.  It doesn't help when they first ask how big user stories are and my first response is "it depends". It's not uncommon to find team members asking if they can call smaller stories a minor or sub-story or a larger story a major story.  But then they get distracted by colors of index cards or some ancillary attribute.

The Distinction

Those who identify what the business wants (you may call him or her a Product Owner) take a stab at breaking down stuff to manageable chunks.  You can call those chucks an A/B-level requirement, epic, theme, feature, or spike. It doesn't matter what you call it.  But when the team estimates that stuff, it is still sometimes (more often than not) too big to fit into a sprint or iteration or just isn't ready to be worked.

We need to label [this] to set it appart as work that will be committed to next.  Either it will be scheduled in an upcoming sprint or it will be pulled to the next step on a Kanban.  To be clear, I'm not saying the team should start working on [this], merely because they think it is small enough to be completed within a predetermined cycle.  Until your team has sufficiently defined and mapped requirements, developed acceptance criteria, and removed all known blocking dependencies, it is still not a Qualified User Story.

Though I still use the term User Story as that placeholder for conversations, I believe the Qualified User Story more appropriately identifies a placeholder for conversations that meets a definition of ready and allows the team to commit to complete something within an estimated period of time.

Image Source: Pictofigo HT: Originally posted at LeadingAgile

Write the same but different words

It's all in how you say it. Or, in the case of this video, how you write it. In less than 2 minutes, this video will send a powerful message. It's about writing from perspective. After watching it, I immediately thought of how a user story can communicate a message differently, compared to a standard "shall statement" requirement.

Here are as few formats for you to compare. Which would you use?

As a <role>, I want <goal>

As a <role>, I want <goal> so <reason>

Given <dependency/constraint>, as a <role>, I want <goal> so <reason>

Do you have a preferred user story format that you use?  Please include it as a comment and have a beautiful day.

See Dick See Dick the PM Run

dick_jane_sally

See Dick.See Dick run. Run Dick run.

See Jane. See Jane run. Run Jane run.

You get the idea.

When I was in the first grade, those were the first sentences I remember reading.  I remember being frustrated by this because this isn't really how we talk.  Well, actually, it isn't how I talk.

I suffer from a self-described affliction called over-descriptivitis.  I can't help but elaborate on any and every idea I'm trying to articulate.  I never thought it was a problem.  I merely communicate the greatest level of granular detail to my recipient and allowed them to filter out the extraneous information.  If my wife asks me what I did at work today, I will tell her everything in chronological order.  TMI?

My wife is very forgiving when it comes to me offering more than she asks for.  Sometimes she just puts her hand up and asks, "can I have the abridged version?"  My over-descriptivitis was even addressed in our wedding vows.

I promise I will tell you the time, not how the clock was built.

So,what's the point I'm trying to get across? It's about articulating requirements.  It doesn't matter if you're using shall statements or user stories.  You need to go into enough detail that the person reading it understands your need(s).  After you decide on your format, try to be consistent.

Formal shall statement format: The [activity] shall [desired outcome]

Standard user story format: As a [perspective], I want to [activity], so I can [desired outcome]

Though it may be my over-descriptivitis acting up, I prefer using user stories.  I like the fact that it paints a clearer picture.

How about you?  Do you prefer formal shall statements or user stories? Why?

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?

Ask Derek - Required Experience to take the PMP

I'm always looking for ways to help others in their quests to be better project managers.  It doesn't matter if it's about getting the PMP® certification, getting PDUs, or even finding good tools to make a given task easier.  I field questions from both emails and Twitter.  Today I read an email that was not unlike others I've answered directly.  But, I thought others would benefit if I answered publicly.  Here is the content of the email:

I read your article about how the PMP certification is commercialized and an example of a PMP holder hiding behind the credential.  I want to become a good IT Project Manager.  I read the requirements to become a PMP. According to requirements, a person needs 3 years exp before attempting this test. My question is, how can I get exp without a certificate or who would give me a job to get the exp as a project manager and thereby attempt my PMP certification.  Can you please help me set my goals in an orderly fashion so I can ultimately become a good Manager?

Does this sound familiar? It's kind of like the chicken and the egg.  First, I would like to say the person asking the question made a statement that resonated with me.  I want to become a good IT Project Manager. I really want to help because if they wrote that, they are half way there.  Let's be clear.  You don't need to have a PMP to be a good PM. I know very gifted people who do not possess the credential.  I would be a liar if I did not believe the deck is stacked against them.  Companies have bought into the idea that good PMs have PMPs.  But I digress.  Back to the question at hand.

It can be a challenge to become a project manager, if you have no experience.  If you have ever lead a team or managed a task, you have more experience than you give yourself credit for.  PMI will recognize that.  Remember, the PMP is not a test about something you are learning.  The PMP is an exam about what you should already know and do, but categorized within the framework of the PMBOK.  Let's say you're a QA Engineer.  I bet you have a lot of experience in the Monitoring & Controlling Process Group and specifically in the Project Quality Management knowledge area.  Document your experience around what you know and do.

In order to qualify to take the PMP exam, you do need to have experience in all 5 Process Groups (Initiating, Planning, Executing, Monitoring & Controlling, and Closing).  Honestly, you could have 99.9% of your experience in one process group and 1 hour in each of the remaining 4.  PMI doesn't care.  You just need to document that you have experience in all.  If you want to be a good PM, I would recommend you get exposure to each of the progress groups. Fewer things are as bad as a PM who does not empathize with all of the functional areas or have experience in the different phases of the project lifecycle.

On a practical note, I recommend you engage others in other functional areas of your current project(s).  Offer to help them in some way.  Don't go in with an ulterior motive.  Honestly, help someone and you'll get the experience you need as a byproduct.  The PMP should be for someone with overall experience. However, I do know managers in specific functional areas who also hold the credential.  I would recommend, if you want to be a good manager, to become educated through practical experiences and not solely through academia.  You can learn just so much from a book.

Did I answer the question?  Is it a good start?

Please post some comments and let me know.

Satisfying Needed Scope Versus Wants

traceability

What is the definition of Requirements Traceability Matrix? It's a table that links requirements to their origin and traces them throughout the project life cycle.  Not everyone uses them. There are many templates and means to ensure your project meets the requirements.  But I can't stress enough how important it is to ensure you're working to satisfy the requirements (or scope) first.  I reviewed a vendor's progress report today and realized the very last task they had on their activity list was requirement mapping.  When asked why it was the last item on their list, their response was the activity wasn't on the critical path.  So, how on Earth were they going to know they were done, if they didn't map the requirements first?  Here they are, at the end of a development cycle, and we're being told the requirement mapping activity is just basically a clerical process. Imagine the frustration I suffered, knowing all too well they may have missed something.  Imagine how expensive it could be, to fix at the end versus the beginning of the development cycle?  I'm not saying the vendor didn't do a lot of work or deliver a lot of product.  Unfortunately, they spent way too much time satisfying the daily wants of a stakeholder and took their focus off the needs of satisfying project requirements in the process.

What do you think?  I'm a being too much of a control freak?