Category: Training

Agile Development: How To Write Effective User Stories


Agile Development: How To Write Effective User Stories

A user story is a short and simple description of the customer’s need. It is usually told from the perspective of those who are requesting the new feature or requirement. A user story is short and sweet, but prompts the developer to get a handle on what is required. It makes it easier for the developer to produce an on-target feature of superior quality, and allows them to understand the goals and needs of the customer more quickly. It is normal to write a user story on Post-its or index cards.

Usually, user stories have a specific format, such as the following:

“As a [persona],
I want to [do something],
so that I can [realise a reward].”

This is a sample from my training course where we ask students to use Lego to build features



The user story prompts the user to ask questions, and suggests, for instance, specifying not just any cow, but a cow that can be milked.
Using lego to plan creation of stories

Use the acronym INVEST to get to the best user stories.

So a user story should be all of the following:

Independent (I): A user story should not depend on another one. Dependent user stories are difficult to estimate and prioritise, and removing a dependent user story often causes problems in others.
Negotiable (N): A user story is not just a text detailing the features that the product owner expects, or a piece of functionality that will be implemented. Look on a user story as a starting point for a conversation, or an opening problem for the team to suggest solutions to.
Valuable (V): We cannot just create fun user stories. We must describe the value that the customer will get from this user story.
Estimable (E): There must be enough information to allow the team to make an estimate about the user story, otherwise it cannot be started.
Small (S): A user story cannot take more than one sprint to complete. Any user story larger than this will be impossible to plan or estimate safely. If it’s too big, create an epic and split it into smaller user stories.
Testable (T): If you cannot test a user story, you cannot know whether it’s worked. If a specific user story cannot be tested for lack of information, do not put it in your backlog.
Use themes and epics when necessary.

If you use the INVEST concept to create user stories, and can keep to it, you’ll have good quality stories. In some situations you will see the need to separate them into themes or epics.

Themes: A theme is a group of user stories that share attributes in common. Often, multiple user stories will have similar goals, or be related in an obvious way. All of them are directed together to a single path; however, they do not need to encapsulate a specific feature or necessarily be delivered together. So a theme may contain several epics or several user stories.
Epics: An epic is a great user story that cannot be completed in a single sprint, resembling a theme being built with multiple stories. Although the stories that make up an epic are completed independently, their value to the business may not be delivered until the entire epic is complete. This means that it does not make sense to deliver an epic until all the stories tied to it are complete.
Althris provide Scrum Master Training in Dublin and Cork, check out our PSM sample exam papers.

PMBOK 6 Tailoring


Project Management Body of Knowledge PM Tailoring

PM Tailoring

The Project Management Body of Knowledge (PMBOK) presents the guidelines for best practices that can be applied to projects. It also presents a standardised terminology. PMBOK guideline preparation itself follows ANSI standards, so it is natural that it goes for a standardised terminology! Generally, a single word (or phrase) is used to define or describe a process (or element) of project management. Those who have worked on projects can readily appreciate the benefits of standardised terminology in the project management profession. In the real world, we have seen the confusion created by using different words for the same thing.

One of the important phrases that have started appearing from PMBOK Guide Third Edition is tailoring. The usage of this term in the later editions is growing, and there is an even greater emphasis on tailoring in the 6th edition, which emphasises the importance given to tailoring. Project management methodologies/processes are constantly increasing; and real-life projects are becoming ever more diverse and complex! The saying One size does not fit all goes well here. It makes sense now to throw some light on tailoring.

Tailoring is making project methodology fit. There may be different situations warranting different methodologies and the adaptation of different processes. Industry type, environment, organisational experience, kind of project, etc., may lead to different processes being chosen for different projects. Each project is unique with its own set of goals, resources and constraints. Tailoring is the act of adapting different processes to make them suitable for different projects. The standards, guidelines and rules presented in PMBOK may be general and globally applicable. There is a need to design and tailor the processes so that desired goal is achieved in each project.

The project manager along with his/her team is responsible for the process of tailoring. To quote PMBOK,

for any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process. Project managers and their teams should carefully address each process and its constituent inputs and outputs.

When the project manager and his/her team do this they obviously buy into this.


There can be several stages in tailoring. In the initial stage, the PM methodology may be based on the PMBOK Guide. In the second stage it is more geared towards the elements of the project and based on Organisational Project Management Office (PMO) guidance. The third stage of the tailoring can be at the project execution level, depending on how well suited the processes are for achieving the desired outcome. As we can see, tailoring is done throughout the entire life cycle of the project. Another important aspect to remember is the documentation. There is a need to document the tailoring process approach in the project management plan, and then at the execution stage, in terms of how each process was tailored, and why it was added, removed, or revised.

Four key takeaways from this blog post are:

  1. Tailoring is making project methodology fit.
  2. The PM and team are responsible for the tailoring process.
  3. Tailoring is done in three stages.
  4. Tailoring needs to be documented.

Join the conversation and follow us to get an update on PMP exam preparation or take an open PMP test.

Agile Books worth reading


Agile Books worth reading

How Do I Design A Training Programme?


Designing a Training Programme

I was recently asked by one of my larger customers about how to design a training programme. I didn’t have to think very long about it because I have the answer. Training must be outcome orientated, if you don’t know what you want how can you decide what training is needed.

1) Training Must Be Outcome Oriented.
That means starting with what you are trying to achieve. Particularly the behavior difference that your are looking to change. This is a really good starting point and helps you design the course around the outcome. Training for the sake of training is generally a waste of time.

2) Learners Must Have Pre-Work
Pre-work gets them ready and primed for learning. This should not just be reading but they must have attempted an activity or exercise.

For example: If the training was to include “how to create a charter” because we need better project charters then the learner would be expected to bring a charter with them. Sharing it with the room and perhaps outline 2 good things and 1 poor thing about the charter. This work equally well for user stories, project flows, burndown charts etc.

Online learning with exercises can be particularly good for this.

3) The Class Must Be Interactive With Exercise.
Mature students learn more from each other than from a trainer. This works best if its day-job orientated.

For example “Breakdown a user requirement or story” for our current project. The room can discuss, comment debate the topic with the guidance of the facilitator.

4) Use Games
Games , competitions and real scenarios as exercises, these energize, provide relief but re-iterate the learning if no 3 missed the mark.
For games suggestions have a look at

5) Agree Learning Outcome
Get learners to agrees to implement the learning outcome. The outcome hasn’t actually been implemented so this may still need to be done. It’s the facilitating trainers role to drive this home but an even greater effect can be achieved with short sharing sessions after the initial training.

For example lets meet in 2 weeks time for 30min to see how we all have gotten on.

To PMO Or Not To PMO


When It Comes To A PMO I’m Generally Asked One Of Two Questions.

Do I need a PMO?
How do we keep our PMO relevant in the agile world?


PMO is not a solution looking for a problem
The question generally comes from different types of companies but my response is the same. What’s the problem that you are trying to solve? In too many organisations a PMO is often a solution to an unclear problem. The PMO nay-sayers might say a non-existent problem.

So let’s turn this the other way around and figure out what is the business case for the PMO and ask those advocating it to create a project to support the business case.

We can ask ourselves what is the problem that we are trying to solve and put forward the options to solving it. The PMO should deliver clear benefits via a number of services that it offers. Those benefits should be measurable and if the service offering stops delivering the benefit then the service should be stopped.

The PMO should make the job of a project manager (or Product Owner/Scrum) easier and must deliver a service not just add administration. Setting up a PMO to control or oversea projects is simply the wrong approach.


Let’s Look At Some Possible PMO Services And See What Benefits They Can Deliver

Lessons Learning – this is a great service to offer as it provides an opportunity to share and learn. The benefits that this delivers can be realised with increased confidence in project delivery. Turning this into a benefit, we could measure current confidence, then implement a lesson learning process and see if confidence improves.

Template Database – Easy to do and can deliver results really quickly. For this we could measure how long it takes to set-up a project before and again after so the benefits are clear.

Project Assurance – Audit/Assurance of projects – this can deliver better governance and greater management confidence in delivery. Yes again find a measure.

Programme Management – Supporting the strategic initiatives by breaking down the big picture into implementable projects. This can deliver much quicker kick-off and the delivery of benefits earlier.

Facilitation – running of particular types of workshops. Perhaps lessons learning/Retrospectives, risk/worry workshop, stakeholder engagement. For this ask the Project manager what they want and check if the services makes their job easier.


A few other Services That are Worth Looking at:

  • Capacity Planning
  • Training
  • Governance Protocols
  • Impediment Removal
  • Value Realisation and Value mapping
  • Resource Provision

Signs The PMO Isn’t Working:
The PMO is thought of as a group that checks boxes vs. facilitating productivity
Stakeholders don’t understand the PMO purpose or know how to engage
The PMO is regularly considered for the “chopping block” when budgets are tight
Stakeholders go around the process or don’t engage with the PMO
Nobody is clear what the PMO does
People duck when the see someone from the PMO
Project managers are acting more as fire fighters instead of fire preventers and are reluctant to look for support from the PMO
If you choose to embark on the journey of building out a PMO, remember the following tips:


Keys To PMO Success:
Start small and have (and recognize) wins along the way
Find a sponsor, Engage and figure out the problem that needs to be solved
Create a business case with measureable benefits
Deliver value quickly
Follow a simple maturity model, phased roll out of services
Treat the build out as a project (requires a charter) and the PMO as a business unit (requires a business plan)
And finally don’t just pick the service and offer it, identify the problem and investigate if the service an can support it.

How do you Eat an Elephant?

No matter what type of facilitation training you do, preparation is the key.  How to prep for workshops, requirement refinement, meetings, retrospectives etcThe best preparation is to come up with a vision for the workshop. I have a simple 5 step model for training, I call it AIDED. The model highlights preparation; it’s not about how to run the workshop. Good workshops run themselves, but a great seminar needs organisation.

Facilitation Training in Dublin

No matter what type of facilitation training you do, preparation is the key.  How to prep for workshops, requirement refinement, meetings, retrospectives etcThe best preparation is to come up with a vision for the workshop. I have a simple 5 step model for training, I call it AIDED. The model highlights preparation; it’s not about how to run the workshop. Good workshops run themselves, but a great seminar needs organisation.

Emotional Intelligence for Project Managers

The people side of project management (or any management role) is the hard bit. We have to effect action and change while being conscious that we cant make people do things. We got to get them to take action for their own reasons.

#iguru_soc_icon_wrap_5fbe0ce8f0763 a{ background: transparent; }#iguru_soc_icon_wrap_5fbe0ce8f0763 a:hover{ background: transparent; border-color: #116cb6; }#iguru_soc_icon_wrap_5fbe0ce8f0763 a{ color: #acacae; }#iguru_soc_icon_wrap_5fbe0ce8f0763 a:hover{ color: #ffffff; }