4 Reasons Why agile user stories are not getting ‘done’!

WHY AGILE USER STORIES ARE NOT GETTING ´DONE´!

Hi, I am Chris Roberts. I am the founder of an Agile consultancy called Nimble. I’m delighted to be asked to do a guest blog for Luis on the topic “Why Agile user stories are not getting ‘done’!”. Luis is one of the guys whose work I admire in this community.

A question I often get asked by people (often learning the Scrum Master role) is how do I offer support to someone who is struggling progressing agile user stories?

This may be a scenario where updates are positive but agile user stories just aren´t moving, or a team member’s body language is spelling out there’s a problem even though they’re not explicitly asking for help.

Regardless, the answer to ‘how do I offer help?’ is simple; make your mind and use common sense.

Sometimes we look for Agile techniques and practices instead of asking ‘what would common sense tell us?’

Why does this happen?

This is particularly common in Scrum where some people have

1. either misunderstood the core values of Scrum and treated it like a religion, where all answers to every problem in our working life must come from Scrum (#scrumdamentalists) or
2. have understood what Scrum is and still treat it like a religion because they like its structure because it has some structure have taken that ball and ran with it to treat Scrum as some rigid set of parameters.

What would common sense tell us?

My reaction to observing a team member(s) struggling to progress agile user stories goes something like this ‘Hi Nick, do you need any help with this story?’

Dependant on your judgment of this team member’s character, this may be a quiet 1-2-1 chat post stand up or something that’s asked during the stand-up. If your team is quite mature, they may have developed this heightened sense that one of their teammates is struggling and do this unprompted too.

4 Common reasons we struggle with agile user stories

In my experience when someone is struggling and does need help when you get to the crux of the issue, it normally reverts to one of 4 common reasons:

1.Story is too big

We should keep mindful that stories are small independent requirements that deliver value. Sometimes it isn’t obvious that agile user stories are too big and maybe it’s 2 or 3 that have been rolled into one.

How can we solve this? We can get the Dev, Product Owner, and the Tester together to break the story down into some stories that each have value by splitting out things like alternate paths, edge cases and error cases just as a few examples.

2. Story is not understood (well enough)

Whatever label you would call your team planning session, it should always give the team opportunity to ask questions and check it’s clear and well understood before they commit to working on it. However, sometimes this opportunity can get missed, or a team member discovers this lack of understanding only once work has started.

How can we solve this? We figure out which team members should be involved and have a quick informal session with them to thrash out our collective questions and get answers to them. If the actual requirement is misunderstood, the answer/clarification is likely to come from the Product Owner. If most of the team don’t understand it, it would be useful to grab everyone for a quick chat to share the knowledge and get everyone’s understanding in sync.

3. Team member needs help to solve a problem

The story may be clear on what’s required, but it may be complex and benefit from running an idea past another team member to figure out the approach.

How can we solve this? Chat to the team member to figure out what area of help is needed and using your knowledge of other team members, ensure the two team members work together to solve a problem whether that’s a sketching session or pairing.

4. There is a secret (implicit) blocker not being called out

This is where we may try and work around an impediment instead of stopping in our tracks and saying I can’t progress this any further until we resolve/unblock it.

How can we solve this? Keep probing with the team member until you uncover what the exact issue is. Figure out then if it’s an internal or external impediment. This tells you if it’s something you can resolve within the team or if it needs escalating outside of the team to resolve, by the Scrum Master if relevant. Then brainstorm a quick list of what your options are to remove the impediment. Get help from other team members where needed and come up with an action plan of how you can eliminate it.

What should we do?

So you may have spotted a common theme. In each scenario:

• we pick up and identify that we are struggling to progress a story
• we probe to find out what the reason is and
• then we get people together and talk.

Sounds simple, doesn’t it?! You’d be surprised though how many times you see this type of issue just drift on unnoticed or unactioned.

If you’re in a leadership role, a Scrum Master or even a fellow team member, it’s critical that we know the background of these four reasons as it helps us to understand the problem that person may be facing or internalizing. Once we know the root of the problem, we can then look at how we might tackle it (as suggested above).

It also helps us to be proactive in swarming issue stories to deliver value quicker and keep our team motivated.

Working with Me Or Evolution4all

I have developed the “Organisational Mastery” product. The aim of this product is to create a coalition that drives change and internal innovation alongside shared knowledge throughout the organisation. It’s extremely suitable for companies that want drastically improve the alignment between executive leadership and delivery teams.

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.