Training on User Story writing

Replies to This Discussion

Permalink Reply by Per Lund on January 6, 2010 at 7:30pm

An approach that we have been quite succesful with, is to have our developers go through a certified scrummaster course. It gives everybody a common understanding of the methodology.

▶ Reply to This

Permalink Reply by Les Oliver on February 9, 2010 at 6:21pm

I'd suggest a Workshop rather than a training course, and one that is specific to your environment, culture, projects and people. That way it's not "Vanilla", it is specific to your needs and it can address other related areas that may be appropriate outside of pure "User Stories".

▶ Reply to This

Permalink Reply by Kelly Waters on February 13, 2010 at 9:49am

I can't recommend a specific training course or trainer, but I would heartily recommend you read Mike Cohn's book "User Stories Applied"

I've also written quite a bit of content on user stories that you might want to have a read through. In particular you might be interested in reading this one and following the links in it -

Writing Good User Stories

Hope that helps,
Kelly.

▶ Reply to This

Permalink Reply by Rick Webster on February 23, 2010 at 4:07pm

We were taught a formula, or template for writing user stories. It goes like this:

"As a user, I would like to perform some function so that I can accomplish something ".

The user would be a specific type of user, and function is sort of self explanatory. The "accomplishment" was where we had the most difficulty, but was probably more important than anything else. If there were no accomplishment, or it was weak, then there might not be a good reason to implement the function.

Here's a contrived example using the popular site LinkedIn.

"As a programmer, I would like to be able to fill out a skills section in my profile, in order to be able to network with companies and individuals who are in need of my skills."

We call this type of story an epic, because it was too large for a 2 week sprint. So during our story grooming sessions, we would start to refine this into smaller, more manageable pieces, until we felt like it could fit into a sprint. Then during sprint planning, the team would all size the stories. If the team thought they were too large for the sprint, they would go back for more grooming.

One of the reasons this worked well for us was the length of the sprint; 2 weeks. If the sprints were any longer, some user stories may have been sort of forced in, and there was a potential that a story would not be finished during a sprint, which was not acceptable. And if a story needed more grooming after it had been sized by the team, it was only two weeks later that the new stories had the potential of being pulled into the next sprint.

Hope this helps, and doesn't confuse you further.

▶ Reply to This

Permalink Reply by Rick Webster on February 24, 2010 at 10:42pm

Also, see this:

http://now.eloqua.com/es.asp?s=1092&e=13514&elq=16d19695eab...

▶ Reply to This

Permalink Reply by shabbir on February 25, 2010 at 8:29am

Recently we have gone through the same exercise. One way is you learn yourself - going for training and then coming back with your own skills.
The second way is hire one or two people (for one for each role you are aiming for) from companies like Thoughtworks or Valtech and do one or more project with them.

I would like to recommend the second way because you need someone experienced all the time during the course of the project. If you get training you will find it difficult to adopt as you are doing a project and you don't want to risk your project either. I personally have gone through these two methods and would recommend brining each experienced role on board to kick start.

Thanks,
Shabbir

http://agile-software-testing.blogspot.com/

▶ Reply to This

Permalink Reply by Les Oliver on February 25, 2010 at 9:43am

I agree with Shabbir, experienced based on-project Coaching is always best.

I would also add companies such as RADTAC and Connections Agile Services to the list of potential suppliers of high quality Agile Services, Training and People

▶ Reply to This