– Back to the Agile Practice Guide (all) –

The Agile Core Practices

There are certain core Agile practices you might be doing as a team – and not necessarily calling yourself Agile or using the framework names, but still working in an Agile way. Knowing these core practices is a great way to get a deeper understanding of Agile as an approach.

One of the best places to update your skills in Agile is from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. This one in particular is collaborative user story creation.

Collaborative User Story Creation

With collaborative user story creation, it’s important because poor specifications are usually a major reason for project failure. We may have specified what the customer wants, and then when they actually get their hands on it they may actually have wanted something different. Or we may have misinterpreted what they wanted in the first place. Al of this results in them not really being happy with the end result. So poor specifications are often that major reason for project failure.

In Agile development, user stories are written with with a lot of the people involved, from the customers through to the people creating the product. We’ve got the developers who are developing our product, testers, business representatives or the product owner in the whole team approach. We have frequent informal reviews of the things that they’re creating just to make sure that they’re right, and everyone who needs to be is always involved.

It’s always an ongoing conversation to check if we need to adjust.

You’re probably seen the User Story – looking at the Kanban approach, a User Story is often represented as a card on the Kanban board. It goes from the backlog all the way across the board into “done” and these can be whatever you want, for example “in progress”, test or design sign-off. This user story that we’ve created during our release and iteration planning, it addresses both the functional and non-functional requirements of that particular feature.

It also includes acceptance criteria, so we know what success looks like. It also must be estimable, so we must be able to say “It’s going to take me three hours,” or three points if we’re working on points. The team might have 20 points for the week for example, and it must be small enough so that we can really break it down to a manageable piece of work. It must be testable, so we must know exactly what does “done” look like, what a success look like and can we test that.

It definitely has to be able to be tested and with the testable part often the test is written or the acceptance criteria is written as “Given, When, Then,” which is Behavior Driven Development, another auxiliary part of Agile. All that is given a certain scenario when “this” happens then I want “X” to happen, and that’s the part that we want to test to make sure it’s happening.

There are also three C’s of User Stories – we’ve got the:

Card
This is the physical card, and it’s describing that User Story. It identifies the requirement, its criticality, expected development and test duration, and the acceptance criteria for that story.

Conversation
This explains how the software will be used, evolving in conversations with the Product Owner and developers. So everyone is always talking – you’ve got the Product Owner representing the customer and you’ve got the developers creating the products, you’ve got the testers testing that acceptance criteria, maybe you’ve got Design in there and a few other members within your whole team approach in your cross-functional team. Everyone who needs to be there is in within the team itself and everyone is having that conversation. The customer and the product owner representing them – this is describing the person who’s getting the benefit of the product or project. It is “I want this, so that I can do that.” And that’s another great way to describe that User Story.

Confirmation
This is the acceptance criteria. It shows us when we’ve reached our goal of creating what the customer wanted, for that particular story or that particular card. It’s discussed during the conversation with everyone involved in the whole team and it’s used to confirm that that story is done.

And that is collaborative user story creation.

– David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

View All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable. You can get the whole book on Amazon here and enjoy your own copy.