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

The data has a better idea? AI in project management

Is it sensible or practical to introduce AI into project management? There has been a lot written about this subject recently, some predicting the end of project management as we know it, some predicting radical changes in the project management processes we use, some even suggesting that project managers will be replaced by computer models and intelligence.

In this blog I want to consider the practicality of automating a manual process like project management.

The world has spent many years automating processes and I have been involved in many projects using software systems at the heart of the automation, some successful, some less than perfect, some a disaster.

Can we automate project management?

What sort of data would we have available for our bots to work with?

Let’s start with the lowest level of detail because that is usually reasonably accurate data relating to tasks being performed by members of the teams. This data has two main inputs, the predicted and the actual.

Can we automate or use AI on the predicted data? Usually this is based on experience and would very often have a knowledge bank somewhere, either in the form of a standard schedule of rates, or data from previous similar tasks or product development. 

Of course we all know that things can go wrong with predictions, which is why we have project managers in the first place, if everything is going to go according to plan, we don’t need a project manager it can manage itself. But the data to predict the effort, cost, timescales, scope and quality is available for AI systems to be able to access. AI systems would be able to analyse historic data and put some form of confidence factor on the plan and our schedules may well be more predictable. Probably.

Collecting the actual data? Can this be automated? This will very much depend on the type of work being done. If it is IT based it is possible to make a link between the size and headings in a document or spreadsheet and analyse the progress information, possibly. If the project is producing new software it could analyse the number of objects created, number of tests run, number of bugs or warnings the compiler flags, this could give some degree of confidence in the actual data.

We could even have some data from construction projects and more manual tasks as the deliveries get made, weight of materials used etc could be combined to provide us with reasonably accurate progress data. 

Would this machine collected data be any less accurate than data collected by team managers and reports from people? How accurate are progress reports anyway? How often do people enjoy writing a progress report? If we have a timesheet or task management system how accurate is the data?

There seems to be some value an AI system can add at this level if, and only if we have some experience with the tasks, some previous data about the tasks, some knowledge base about the disciplines in a machine readable format.

One question I would ask at this point is, would we expect the performance of the teams to improve as we complete the tasks more frequently and at what point would we say, this is as good as it gets. 

Moving up the chain a little, away from the task details, project managers issue work packages which is the PRINCE2 term for asking a team to do some work, but whatever term we use, project managers need to ask people to do some work.

Could this benefit from AI?

The project manager would have a plan relating to the dependency of work packages, the available people, internal or external, stakeholders, risk mitigation, changes from the original scope, issues that occurred since the baselined plan.

That is a lot of data, and reasonably well structured, how could AI help? Would we want the AI system to send out the work automatically? Sounds reasonable, the plan is available, the date approaches, and assuming the progress information has been updated it should be straight forward. If the resources are internal they would probably have access to the same system as us, if external there is often links into systems to trigger purchases and contracts.

Good configuration or asset management and change control is very often automated these days in the IT world, so if things have not been completed as planned or changes have been made the system should be able to detect this, analyse and evaluate the possible scenarios and using the data, send or delay the sending out of work.

Of course this is where the majority of issues occur and where we must be managing risk. In terms of managing risk, Monte Carlo analysis and probability should give us an understanding of just how risky a task is, there are many systems available to help, but is this artificial intelligence or brute force scenario based? For now let us assume that we do not care about the difference, we just want to mitigate the risk of delays, cost overruns, quality control failures, scope variability, complexity of task, the weather, sickness, computer updates (daily), internet connectivity, mistakes being made, fall outs between team members, rumours of strike action, strike action, lockdown responses to a virus, a flat tyre on a delivery van, lost car keys, trips, falls, accidents, childcare, elderly care, mental health and stress, fire, fire drills, morning after the night before, morning sickness, accidentally deleting a file, emails going into spam, confusing work instructions, misunderstandings about the work, disagreements on the work, unwillingness to do the work, BAU taking priority, customer complaints and firewalls.

That is a lot of data.

And AI likes a lot of data, but I suspect the project manager might not want the AI system to automate the sending out of work packages even if it could.

One of the other uses that AI should help with is decision making, too often decision making is done emotionally and intuitively usually based on our own professional experience with extreme personal or political bias rather than with data. 

A change towards a data and fact-driven approach will take into consideration past challenges, learnings and plain facts, is a fundamental and radical change and requires a true mindset change. 

Almost all projects require decisions to be made all the time, let’s start at the first decision in PRINCE2, which is to approve the project brief before the PM starts the detailed planning. The decision is, do we bother with this project at all? Is it worthwhile? Do we know what is required? Do we know how we are going to deliver the project? Do we know who is going to help us? Have we done this before?

Historic data, and broader knowledge could be used to help with those decisions. Plus, do we have the capacity to start planning the project, do we have a project manager with the right skillset available? How many projects can a project manager manage? Depends on the scale of the projects they are asked to manage and this could be data driven based on complexity scoring which would require a project brief, and we have one of those, prepared by a project or programme manager.

 We won’t talk about AI preparing a brief just yet.

I believe we are a long way off, and particularly as we move towards more agile approaches to project management, self-organising teams and low tech visual planning.

See my book for help in transforming a PMO into an agile world very simply.

Agile PMO's (Simply)

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