User Stories in project management and more...

 User Stories

Agile teams use a concept called User Stories which is a simple concept and structure:

As a … (role)

I want … (some feature)

So that … (some value)

Here’s a reasonable example

As a project manager

I want scrum training

So that I can improve my relationship with the developers

That would NOT be considered ‘Ready’ because we have no idea what effort is required, no idea what level of training is needed, no idea about the current relationship and no idea what type of projects they manage. Once we have this information the User Story (or Backlog Item) would be ready for someone to start work.

The structure of a user story is simple enough and can help a team understand how features add value. 

As a phone user with an almost flat battery 

I want my charging lead to not work because it is not an official Apple one

So that I am unable to use it until I get home. 

As an ear bud listener 

I want to have to re-select them

So that I keep the caller waiting for a response. 

As a music listener 

I want to be deafened by the screen off button 

So that it disturbs my listening pleasure 

As a LinkedIn user

I want my posts scanned for political content

So that the fact checkers can check the checkers

Edit Jan 2023: 

As a MacBook Pro user

I want a software update that crashes the thing at least once a month if the battery get low 

so that Apple can force more updates on me

Now of course most of the above stories are not real ones, but it is an interesting way to see the value that user stories hold, and here's a little tip, if you are raising a help desk ticket or logging a complaint about anything technology related, try using the user story format, you would be surprised how the support teams will react.

As far as a PMO is concerned, the user story concept is a great way to start thinking about your projects and programmes, it gives a very clear vision from day one.

Software developers might balk at some of the user stories, complaining that they are too large, these are called EPICS, but the format is the same and epics get broken down into smaller user stories in a similar way to breaking our projects into stages and programmes into tranches.

User stories are similar to PRINCE2 product descriptions, the main difference is that a product description is usually a document formally signed off and agreed. User Stories are a starting point they do not fully define anything, they encourage, deliberately, further discussion with the customer or product owner. How is that any different from most project mandates?

Agile, scrum in particular, starts with the premise that the work has already been justified in someway. User stories include the “so that…” which implies value is being delivered and one could argue that this does, to some degree, justify the work. Also the product owner and customers have asked for these features to be developed which also justifies the development. The danger for project and programme managers is they try to put measurable benefits on every user story, this is usually not needed and the bigger picture project is where that should happen, not at the detail.

I hope you enjoyed this and gained some value from it, should I put any measurable benefit on that value? 

For more help on how to make a PMO (Simply) more agile please try this:

Agile PMO's (Simply) - Apple iBooks

https://www.amazon.co.uk/dp/B0BH5477LM

Making MOSCOW work

 

Of course this is nothing to do with the Russian city of Moscow, but images for prioritisation do not inspire much emotion, please forgive me for trying to capture attention.

MoSCoW prioritisation

This is commonly used in the agile environment, particularly during planning and during a sprint. 

Simply put:

MUST - this is something that must be done, without it we will probably fail.

SHOULD - this is something that is important and should be done, but we won’t fail without it.

COULD - this is something we could do if we have time.

WON’T - this is something we won’t be doing at all because at this time we don’t need it (out of scope in project terminology)

What could be easier than that?

The challenge comes with the definition of the word ‘should’

It means two things depending on the intonation.

We should do that, or, we SHOULD do that.

The first intonation of ’should’ would indicate it is ok not to do it, the second implies that we really really SHOULD do it.

This image of prioritising a ball point pen illustrates what we mean by SHOULD, if your project was to only deliver the ink refill (MUST) and NOT deliver the SHOULD, your project would have failed. Yes the customer could actually write something, but they would not be happy.

If you decide to use this prioritisation technique you need to make it very clear that the word should means, like in the pen example, that you SHOULD do it, otherwise the technique falls into disrepute quickly. This is because users and customers will rapidly learn that the chances of getting a should delivered are minimal and the could’s have no chance of ever being looked at, therefore they, quite reasonably, decide that everything becomes a must.

Agile improves on MoSCoW in other ways too, in particular having  fixed time and cost. In other words zero time and cost tolerance, and this doesn’t mean that you can finish early either, allowing a sprint to complete early can have a detrimental effect on MoSCoW too.

If we have flexibility for time, this means we can finish a little bit late or a little bit early. PRINCE2 calls this time tolerance.

If we have a backlog of requirements to complete with several sprints, which is the normal manner in which scrums and sprints are used, we would naturally start with the MUST have requirements in the first sprint, then finish the must haves in the second sprint but include some SHOULD haves too. 

This would normally mean we have some time at the end where we don’t have enough to complete another must have or another should have, some teams will then stop that sprint and start another one so that we can get more MUST’S and SHOULD’S done, and the COULD’s get pushed aside.

The alternative is they extend the sprint a little bit to get the next MUST or SHOULD in because they tend to be larger than the COULD’s

With that thinking, the could’s never get done, and MoSCoW falls into disrepute once again and the users are back to making everything a must have requirement.

ALSO, at the end of each sprint we want to have a sprint review and a sprint retrospective, if we allow the time to be flexible they get skipped too. 

For more help and guidance to make any project office, simply more agile:

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM