Monday, 5 May 2014

Monday Thought: Tell me a story!

From: Murilo Lessa <murilo.lessa@>
Date: Monday, 6 May 2014 11:37
To: Dev All
Subject: Monday Thought: Tell me a story!

Because of the bank holiday and our Sweden trip I have being late with these regular spams so there it goes…

Once upon a time…

“User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
They typically follow a simple template: As a <type of user>, I want <some goal> so that <some reason>.

They strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.”
-- Mike Cohn, one of the contributors of Scrum


Are we solutionising or are we code monkeying?

The SEO Team have an issue: they want to improve our SEO ranking. They think they have a solution for their problem and explain it to the PO. PO writes the story which informs the developers what they should do. The “story" comes to our planning, a technical description about what should be implemented. It seems simple, it’s a 5 we say. 

Clive starts to work on it. He opens the code and finds an issue with the proposed solution. He calls the SEO peeps and they chat for a while. It turns out that the story becomes 3 more stories because the original one has not fully scoped the issue. Where did we loose time?
  • We lost time when the story was discussed with PO and the developers without the main stakeholders present (the SEO team)
  • We lost time with an estimation of a story which was not ideal
  • We lost more time having to chat again with the SEO team
  • We lost more time writing new stories
Does "SEO - Redirect HTTP response update from 302 to 301” sound like an ideal user story? Does this sound like the proposition of a problem that can be solved by a self-organizing team? Or are we just jumping the whole story writing phase and using “BDD" scenarios to specify how technical solutions – only passed along to the dev team - should be coded?


How hard can be to let Developers think about how to do their own work?

1. SEO team needs something to be done! They speak to the PO and a rough User story is written explaining what is the beef…

2. Grooming day: PO, devs and stake holders get together for grooming that particular story. The problem is presented. SEO guys may even explain what they think we should try to address the issue. The team discuss a solution and comes up with the necessary items to do it + any new additional stories that are needed to address the whole issue.

4. PO get these items and with the help of developers stories are written and can now be estimated.

5. Later in the process, when a developer starts the story he might need to again check with PO/SEO guys any further items that might require clarification

6. Done. Validation with PO and SEO team


Thoughts?


Further References:


This is part of my email experiment - sent every 2 weeks - with the dev team I am part of, aiming to inspire them to acknowledge and question What do we do, Why do we do it, and How do we it

No comments:

Post a Comment