pmmagazine.net

Your monthly dose of insightful Project Management articles

pmmagazine.net

Your monthly dose of Project Management articles.

User stories turn requirements into motivators

I am working on a complex project that involves the collaboration of many subject experts, all contributing their best ideas for what is needed. As you can imagine, there is plenty of opportunity for scope creep, so I wanted to share my practical tips for how we are treating every idea with respect, but ensuring we are still focused on delivery on time and on budget.

The secret to our success is the application of User Stories to ensure every idea is described to the same level of detail. This means that we immediately filter out any half thought through requirements, as each of the 4 key pieces of information must be completed for the requirement to pass through to the next stage.

Lets look at the value of each of these four pieces of information:

 

 

As  a….name at least one stakeholder who needs this functionality. This ensures that what we are creating is not only technically correct but it is focused on the needs of our customers. In my experience, the “As A” field in User Stories is sometimes a role within the IT function, because they need something to be included to ensure the accuracy or workability of the solution. I am not going to reject these requirements, but I would be concerned if these were the only ones being included. What I am really looking for on all of my projects is customer-centricity. I want to know that what we are creating meets a business need, that someone is going to be an enthusiastic recipient. Without that enthusiasm, there is very little chance that what I am creating will ever be fully adopted into operational use. In this context I love the word “recipient” because it means receiver and beneficiary. By putting at least one internal or external customer in this field, I am making sure that someone will benefit from this part of the project.

I need…take note, the word is need, not want. Need means essential or pre-requisite, but want means crave or aspire. To keep the scope of my project from expanding, risking my on time delivery, I will socialise the difference between these two words so that everyone who is coming up with ideas knows that they will be prioritised based on how essential they are.

So that – this is my favourite part of the User Story because it our chance to identify what benefits will be achieved. To help generate ideas, I create a list of benefits that they can choose from including:

  • Cost decrease
  • Revenue increase
  • Positive social impact
  • Improved organisational reputation
  • Customer satisfaction
  • Staff engagement
  • Regulatory compliance
  • Streamlined process
  • Increased relevance

Obviously you can add many more to this list but it does help people think through why they need what they need. The more benefits they can identify, the powerful their idea becomes and the higher up the priority list it goes. Equally, if people are struggling to identify why something might create value, then I can suggest that the idea sounds great, but perhaps it is not as essential as some other ideas. Why don’t we hold onto it, and if we get time, we can revisit it later? This is an elegant way of keeping the project scope under control without making the idea generators feel as if they have come up with something silly.

Acceptance criteria – I find this factor brings the requirement to life, it gives us so much useful detail. By trying to work out on what grounds a piece of work would be viewed as complete is so helpful. It makes us think through its usability, how it will work operationally, what constraints will apply and perhaps what assumptions we have made. It drives out so much extra information about format, content, when it might not work, where it would and would not be most use. Sometimes this generates more benefits, or helps us tighten up the description of what is needed. The depth of this discussion can drive out a better understanding of which stakeholders need it and under what circumstances they would use it.

Even if you are not working in an agile way, writing up requirements using the User Story format creates high quality information that improve our chances of successful project delivery. If you want more about this subject, connect with me on LinkedIn where I regularly publish content.

 

Exclusive pmmagazine.net šŸ’¬

Melanie Franklin

About author

Making the case for Portfolio Management

Melanie Franklin is a globally recognized thought leader in change management who has effected business change programmes across public and private sector organizations. Based in London, UK, she is the Director of Agile Change Management Ltd and Founder of the Continuous Change Community. An impressive array of clients in Europe, the US and the Middle East benefit from her unique insights into change. She designs and runs in-house programs to develop skills in change and transformation and advises boards on strategies for change. She is Chief Examiner for the Agile Change Agent qualification from APMG International and works for several professional bodies to help grow the consulting and change management professions. She is the author of several publications and a regular keynote speaker at various conferences worldwide.
View all articles