The intersection of technology and leadership

Category: User Stories

Swarming on Stories

On leading a new team, I’m definitely trying to be as open to trying new practices particularly as I feel it is an important part of The Beginner’s Mind (topic to be talked about at InfoQ). One of the new practices we tried last week was swarming work on a user story.

Normally, our natural work in progress limit for development is limited by the number of pairs we have on the team (although not all tasks need pair programming). This time, I’m the odd one out, acting as tech lead and needing to do a handful of other activities including working to maintain constant flow between our BA and QA functions and guiding the development in the right direction. In a different world, I would have started a story and with other duties, probably be quite interrupted in flow to completion.

This time, we broke down a story into as many tiny tasks as possible, discussing those that needed some design elements, or identifying those tasks that could be taken in solo (such as knowledge gathering with report back) and the three of us worked on the same story. The result was a very minimal work in progress limit and actually, we made a lot of progress in a rich environment where we are learning about not only the constraints of the current build and development systems, but working out the best ways to implement what we need and deliver value.

I’m quite happy to report that I’m really liking the swarming on stories. It helps me feel involved in the way that things are going, rather than keeping on top of too many ongoing threads. I do wonder how many people it would be to scale to, but for now, it’s working for us. Inspect and amplify, or inspect and adapt!

Picture kindly borrowed from Max xx’s Flickr stream under the Creative Commons licence.

Putting the “user” into user stories

I’m helping to kick start a project where we’re identifying enough user stories to help build a solution towards a tight deadline for legal compliance. We’ve been making great effort at identifying and talking through the users of the system, particularly exploring how difference users have different needs. We’ve managed to talk to existing users of a similar system, and talked to people who will manage the new users. The hard bit is that our real system users don’t even exist yet.

My work colleague, Alex McNeil, will be proud that I’m pushing for the UX flag and we’ve finally got a UX person onboard which I’m delighted with. I think it’s worth fighting for guerilla UX whenever and however you can get it. In this case, more is always a better thing for end users. I want to be proud that users actually use all the features we build and enjoy using them at the same time. Without properly understanding who they are and what they are trying to accomplish, I’m confident we would have ended up with a naff system.

Also, unlike some developers who want to jump in and start coding, this part of getting into the mindset of a user you’re targeting is a key attribute to the proper use of user stories. Focusing first on understanding what problem your users are trying to solve is the key to building what is actually neeed. I’m not the only one in the agile community to feel this way, with many people inverting the classic and now dated, “As a … I want … so that … “ story format made popular in User Stories Applied.

We’ve made plenty of headway in the right direction and although I know we can take the UX much further, constrained by client expectations, time-conscious of a pending legal deadline. Don’t worry though. We’ll be trying to live out another agile principle of getting fast feedback, even if its done using other guerilla user experience methods.

I care about emphasising the user in user stories because I don’t want to be responsible for one of those systems people loathe to use. I hope you will care about it too.

How much detail do you put into a story card?

Most of the teams I work with prefer using story cards to capture and manage requirements. For analysts who write story cards, it’s important to remember that they are that “placeholder for a conversation” and it’s useful to know about the three C’s, and understand the INVEST principles that make more ideal story cards. In this post I’m going to answer the frequently asked question: “How much detail should go into a story card?” Of course, please remember that this is just my answer to the question and unlikely a definitive one.

Before I begin to answer, I guess it’s important to understand why we even bother with story cards, something definitely worth a whole other post (and I’m sure there’s plenty of great ones out there). I’m going to distil this to just the essentials and skip the why (you can read it in other people’s posts). For the purpose of this post, I’m going to assume that story cards:

  • Exist to help people have conversations about a small set of requirements
  • Have an associated cost (an estimate)
  • Offer some business value to people such as stakeholders or end users
  • Help stakeholders prioritise requirements
  • At some point may be implemented

The Short Answer
You want to have enough detail to meet the objectives above balanced against the cost of capturing and maintaining that detail in order to support as much change as possible.

The Long Answer

I like to draw the diagram below to visualise how much effort I’d put into collecting detail.

For stories that need to be implemented now, you want to have enough precision that allows developers and testers to be clear about what needs to be achieved. The waste of not having enough detail here is essentially rework in many of the downstream activities. If critical detail in a story is missing, it will lead to misunderstandings that, in turn, leads to bugs that, then, leads to additional coding time and additional testing time, delaying delivery of the business value. What is important at this stage is that everyone involved (the business, analysts, developers, testers, etc) share the same detailed understanding of exactly what is being delivered and what is exactly not being delivered.

Story Detail

For stories that need to be implemented in the distant future, you don’t need the same level of detail. The waste of capturing too much detail too early is essentially rework at the analysis level. Depending on how requirements are managed, this can be costly. Conditions change that may change requirements not yet in production, and I’ve seen many analysts who’ve written down so much detail and invested so much of their own time that they refuse to deal with the change. The want to avoid the change because they now have to rewrite reams and reams of documentation, or drop the last month or two of work to develop a different and better solution. What you need for stories in the distant future is enough detail to allow people to have that conversation over the same thing without confusion, whilst minimising the cost of capturing detail unless it impacts things like estimates, priorities or business value.

The Summary
Although it sounds like I’m saying don’t worry about future requirements, my emphasis is all about balance. You want to balance the costs associated with collecting and maintaining details for requirements that may or may not end up being implemented. Precision has a cost associated with it, and this cost always needs to be weighed up against its value. Excessive precision too early may increase cost via additional rework at the analysis level. Lack of precision too late may increase cost via additional rework in downstream activities such as development and testing.

Further References
James Shore writes more about the life cycle of a story and when you might want to start creating them. Read about it here.

© 2017 patkua@work

Theme by Anders NorenUp ↑