Every person whom I meet teaches me how much I don’t know about some subject. Either its about the world, history, culture, religion, different industries… whatever it is…This happens to me all the time when travelling. I have some luck to have good company most the time while travelling or in transit. Those strangers ended up being my “friends” frequently.
This time when I was travelling from Frankfurt to Doha, Some stranger fell in to conversation with me after seen my notebook bag ( I think I have mentioned about this notebook bag before in this blog J ) He assumed that I work for an IT company and he is an Agile management consultant based in Denmark and travelling to Doha for some assignment. You can imagine now.. a conversation in a long flight extended by 1 hour delay J
It was very interesting to know about various experiences we both had with Scrum and he was quite used to many other agile methods which I have never been exposed to before. However we both agreed that Scrum is the most popular Agile (According to him.. “The well marketed and money making Agile”) right now.
Talking about various experiences I asked his experience about user stories. This was some challenging area in Scrum projects. Getting the user stories right…
I always believed its better to have the standard for user stories “ As a “, “I need to “ “So that I can”.. In this way the requirements become much clearer to everyone and we may not miss the users what their expectations etc.. But he disagreed. I was surprised, but he had a valid argument on this. Example: As a Job applicant I want to post my CV to the job portal so that the prospective employers can view my CV in PDF format”
His argument was that its always difficult to stick with real users in user stories. As an example; you want to have date widgets in an application, so that do you write “as a designer I want to use the list of widgets so that “…….. ??? Where is the real user in this user story? ? I couldn’t agree less. Because I just completed a project initiation where there were many many user stories which I couldn’t think of mapping to my standard template originally but I had to do it by force with tweaking them by using developers, designers , architects as types of users which may not be the best case.. He also had the same experience .. One of his initial product backlogs 80% of the time it has been “ As a product owner “ which doesn’t make any sense…J
But then.. Million dollar question.. Why Mike Cohn standardized that user stories in a standard way? Didn’t he see this problem? I don’t think so .. Need much more thinking and reading on this.. may be some times not using standards would be better than using standards if they are not meaningful.. I will definitely do a follow-up post on this..
Anyway bottom line out of scrum is that speak to anyone who try to make a conversation with you…never know what they will come up with J
Yeah Im not a person who can live with open ended questions.. So Im chasing answers:
28th June..
Follow up today : I purchased the book from Amazon "User Stories Applied: For Agile Software Development " by Mike Cohn
29th June
I found this article :
Missing Dimention of user stories : Interesting thoughts:
3 comments:
Few things in particular I would like to address regarding User Stories!
There is a valid reason Mike has insisted on getting the User Stories done in a standardized format. (Format can be adopted to your unique requirement, sometimes multiple formats can be used based on the context)
The term 'User stories' goes aligned to other agile terms such as "Close Customer Involvement - inception to completion)", Customer Priority, "Changing Requirements (Embrace changes)", Prioritization and De-prioritization.
Even though, the team or PO involve in User Stories. Its under full Control of the customer. At initial stage, the PO and the team might help the Customer for getting the first few stories flow in. As the project progresses the customer is well equipped with those terms and he is delivering a well structured requirements for the use by the multidisciplinary team members.
Ok! now the point is Technical Jargon in user stories..
Well, some customers may be technical but some are not. if he is too technical, i think the customer needs to be in the developers seat.
So how do we handle this?
Number one: Put forward a initial technical stack you are going to build up the system.
Number two: Change whenever the new technologies carry more weight than the ones being used. (Team initiated technical changes may not be a customer concern) "I just want the thing to be working!"
Number three: Do we need to remember that I am using widget in the development or any other jargon?
Number four: If you forget PUT IT IN A BRISTLE BOARD WITH CAPS and place it in a place all can see.
Hmmm!
Now a real issue is there are some other valid issues in user stories.
Remember user stories can be broken down to Tasks.
Is it only user story we are worried about?
NO!
Domain diagram, Use Case, Requirement traceability, Version control, Continuous integration.. and many more :(
Conclusion:
User stories are for the poor customer who is willing put his head on to our garbage.
Techies! it up to you to make any document when ever you want and where ever you want. Customer can not understand it most of the time ;) but you can't ask him to pay you by showing that you have spend time creating this and that document.
Customer will pay for the software and remember to give him a user manual :P
Thanks Thushara for giving me a chance to share some thoughts.
Its being long time I put my finger to writing about agile.
There's a lot of article online I have read but a lot of them are very interesting like your article. Its really enjoyable when I reading it. Thank you for the very nice posting and keep up the good work.
Well, I do not think there should be one format for user stories. There could be some recommended in some cases. I like the following one for stories adding value to the business users. I got it from Dan North and modified it a bit with a couple of friends (Ahmed Sidky and Essam Badawi):
In order to [goal/value]
The [role]
[verb] [task]
The beauty of it is that it distinguishes between the goal or value and the task.
Example:
In order to [prevent automated site attacks]
the [Administrator]
[sets up user logins using captcha]
Another example:
In order to [prevent automated site attacks]
the [Administrator]
wants [online users] to login using captcha
Note how it differentiates between the role or personna who has the goal or value and the role/persona whol will actually perform the task
Post a Comment