Archive for the ‘stories’ tag
I was recently reading an article about how to write meaningful user stories and towards the end of it the author mentioned the INVEST acronym which suggests that stories should be:
From what I’ve seen the most difficult one to achieve in a distributed context is that stories should be ‘negotiable’, in particular when it comes to negotiating the way that the UX of a bit of functionality should work.
On most of the projects that I’ve worked on the people designing the UX tend to work slightly detached from the development team and then send their designs over as wire frames.
It’s not the most ideal setup even if you’re working onshore but it becomes even more challenging when you’re working offshore.
Typically onshore if a particular user flow was very difficult to implement then one of the developers might go and talk with the UX guys and then explain the problem and give another potential solution.
The trade off between the cost of implementation and the user experience that the UX person has suggested is clearly outlined in these conversations.
When that feedback comes from offshore it has much less impact and I think it comes across much more as a criticism of someone’s work rather than an attempt to be pragmatic in helping the client to deliver a product within a time frame.
One possible solution to this problem if you have some onshore colleagues is to have them go and talk about the problem but we’ve found it difficult to do that because we try to split onshore/offshore stories so that we’re working on different parts of the code base.
Therefore it is pretty difficult for an onshore developer to go and discuss it for you.
To add to the problem we tend to realise the difficult of implementing a certain UX during the middle of our day which means we need to wait half a day to see if we can get it changed.
Given that time lag we often just end up designing it the way that’s been specified so that we don’t ‘waste’ time.
It’s clearly not an idea situation so I’d be keen to hear if anyone has come up with ideas to get around this.
My colleague J.K. has written an interesting blog post where he describes a slightly different approach that he’s been taking to writing stories to help move the business value in a story towards the beginning of the description and avoid detailing a solution in the ‘I want’ section of the story.
To summarise, J.K.’s current approach involves moving from the traditional story format of:
As I... I want.. So that...
To the following:
As I... I want.. By...
I quite like this idea and I’ve noticed that even without using this story format technical solutions are sometimes described as the business requirement and we need to look beyond the ‘I want’ section of the story card to find the real value and locate assumptions which have led to the story being written in that way.
To give a recent example, a colleague and I picked up the following story:
As the business I want a HTTP module to be included on the old site So that I can redirect a small percentage of traffic to the new site
We assumed that other options for redirecting traffic must have already been analysed and written off in order for this to be the suggested solution so we initially started looking at how to implement it.
After a bit of investigation it became clear that this was going to be quite an invasive solution to the problem and would involve re-testing of the whole old site (since we would be making a change there) before it could be put into production. That would take 2 weeks.
Speaking with Toni and Ashok about the problem it became clear that it should be possible to control whether traffic was going to the old or new site by changing the configuration in our load balancer, Netscaler.
Discussing this further we found out that this had been tried previously and hadn’t quite worked out as expected which was why it hadn’t been considered as an option.
We spent some time talking through using Netscaler with the network team and agreed to try it out on a performance environment and see whether it would balance traffic in the way that we wanted which it did.
We still need to make sure that it works as expected in production but it was an interesting example of how solutions can be excluded based on prior experience even though they might still be useful to us.
I’ll certainly be more aware of noticing when a story details a solution and try and look for the actual requirement after this experience.