Improving your agile flow

I’ve noticed two counterforces to flow on an agile team: rework and human multitasking. It’s common knowledge that rework is wasted effort, and human multitasking should be avoided as it reduces velocity through inefficient human context-switching, and can increase further errors through insufficient attention to tasks at hand.

But luckily there’s two simple things I have found that increase flow and reduce rework and multitasking.

User Story Kickoffs

It is essential that just before development work begins on every user story that a kickoff discussion occurs. This is a casual discussion around a computer between the business analyst, tester and any programmer who is working on the user story.

In my experience this takes about ten minutes standing around someone’s desk where we read aloud the acceptance criteria from Trello and discuss any ambiguities. We ensure that everything that is needed for the story to be considered complete and ready for testing is listed and that it’s not too large nor will take too long to complete.

We have special children’s sticker on our story wall which we put onto a story card that has been properly kicked off.

User story test handovers/shoulder checks

shoulder checks are essential
shoulder checks are essential

It’s also essential that as soon as development is complete that the tester and any programmers who worked on the story gather for a quick ‘shoulder check’ or test handover. This often involves letting the tester ‘play’ with the functionality on the programmer’s machine, and running through the now completed Trello acceptance criteria. Any misunderstandings or bugs can be discussed and resolved before the card becomes ready for testing.

We have special children’s sticker on our story wall which are then added to a story card that has been handed over/shoulder checked. The aim is to have two stickers on every story card in ready for test.

How these two simple activities improve flow

By conducting a user story kickoff every time it means that everyone working on developing the functionality has a common understanding of what is required and therefore there is a lot less chance of developing something that is not needed or misunderstood which requires subsequent rework.

By conducting a story test handover/shoulder check every time it means that obvious bugs and misunderstandings are raised immediately, so they can be fixed quickly before the programmer(s) moves onto working on new user stories. If discovered later these cause the programmer to multitask and context-switch between working on bug fixes and new functionality.

But I’m too busy testing stories…

I used to think that, but now I’ve got a personal rule that regardless of what I am doing or working on, I will drop it to attend a story kickoff or test handover. The benefits of me conducting these activities outweigh any work that I need to resume after these activities are complete.

Bonus Time… is it essential your bugs are fixed?

The great thing about agile software development is that developing something and testing something are a lot closer together… but they’re still apart. It’s more efficient to get someone to fix a bug whilst it’s fresh in their memory, but it’s even more efficient to not fix it at all.

What I am proposing is instead of raising medium/minor bugs against a story to be tested, raise them as bugs in the backlog to be prioritized. Depending on your organization, your business may not consider these important enough to fix, and therefore this saves you both rework and context-switching so you can continue on developing new functionality.

Where is the ‘story’ in user stories?

There’s an old Jerry Weinberg quote:

“no matter what the problem is, it’s always a people problem”

which pretty much describes every project I’ve worked on over the years. Lately, I’ve particularly noticed that most of the tough problems evident on projects are more people or business problems than technology problems, which makes me think it’s worthwhile for me to continue my exploration of the business/user end of my list of software development roles.

BA = Business Analyst
UX = User Experience
ET = Exploratory Tester
TT = Technical Tester
Dev = Software Developer

In this vein, I’ve recently been trying to understand how to better articulate user stories, in that one day I’d love to work as a business analyst.

Most nights I read stories to my (almost) three year-old son as a nice way to end the day. Lately I have been making up my own impromptu stories to keep things interesting. I have really enjoyed making up stories on the spot; I think I’d be a good BA.

But thinking about user stories along with bedtime stories immediately raises a question: where is the ‘story’ in user stories?

Most user stories at work sound something like this: “As a user, I want to log onto the system, so that I can access my information”. What a shitty story! Sorry, but seriously, if I told this story to my two year old son, he’d die of boredom!

I’ve spent a fair amount of time reading about user stories but I still can’t find out why they’re actually called stories, because I don’t think they are actual stories:

sto·ry/ˈstôrē/
Noun:
An account of imaginary or real people and events told for entertainment: “an adventure story”.

The closest thing I have found to actual user stories is the concept of ‘soap opera‘ testing scenarios which outline implausible yet possible scenarios:

“A man (Chris Patterson) and his wife (Chris Patterson) want to take their kids (from previous marriages, Chris Patterson, a boy, and Chris Patterson, a girl) on a flight from San Francisco to Glasgow to San Jose (Costa Rica) to San Jose (California) back to San Francisco. He searches for flights by schedule. He’s a Super-Elite-Premium frequent flyer, but he doesn’t want the upgrade that the system automatically grants him so that he can sit with his wife and kids in economy class. He requires a kosher meal, his wife is halal, the boy is a vegetarian, and the girl is allergic to wheat. He has four pieces of luggage per person (including two pairs of skis, three sets of golf clubs, two 120 lb. dogs, and three overweight suitcases), where his frequent flyer plan allows him (but only him) to take up to four checked items, but the others can only take two each. He gets to the last step on the payment page before he realizes that he has confused San Jose (California) for San Jose (Costa Rica), so the order of the itinerary is wrong. The airline cancels the flight after it has accepted his bags, and reroutes him on a partner. The partner cancels the flight (after it has accepted the bags) to San Jose (California) so it reroutes him to another competitor, who cancels the flight (after accepting the bags) to San Jose (Costa Rica) and reroutes him to another partner, who goes bankrupt after it has accepted the bags for the San Francisco flight.”

~ Michael Bolton

Now that’s a real user story!

So, I think we have two choices on the user stories front. We can either make our user stories actually like real juicy stories, or at least start calling them something else!