User Stories – Focusing on Conversations instead of Writing – Gojko Adzic’s New User Story Book

In my recent article on telling user stories instead of writing user stories, I mentioned that many Scrum Teams focus way too much on documentation and way too little on good collaborations.

More support for this concept comes from the first chapter in Gojko Adzic’s new User Story book, Fifty Quick Ideas to Improve your User Stories.

User stories imply a completely different model: requirements by collaboration. Hand-overs are replaced by frequent involvement and discussions…. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made…. Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations…Engage business stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options. That’s the way to unlock the real benefits of working with user stories.

Gojko has been nice enough to publish the “Tell stories, don’t write them” chapter available completely free here!  It is also important to note, that this chapter is tip #1 in his book, as it really sets the stage for the best use of the User Story practice.

The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth another five minutes of your time to read Gojko’s free chapter, and be sure to share it with your teams and organizations too!

To maximize your Scrum and User Stories practice, bring us into your company to deliver coaching or our User Stories Class.

Breaking News!! Jeff Sutherland’s Scrum Inc introduces “Scrum At Scale” — see it at Agile 2014 session

I was lucky enough to get a preview of the “Scrum At Scale” approach from Scrum Inc a few days ago. In short, it’s a model for conversations around how to think about scaling Scrum in the enterprise. The model is modular, and it is very clear that this approach is more lightweight and flexible than other Agile scaling approaches that get a lot of attention. Alex Brown of Scrum Inc, the Product Owner for the model, as well as Jeff Sutherland, are very adamant that this this not some cookie cutter recipe or methodology to scale Scrum. It’s different than other approaches, in that it’s a model for conversations around inspecting and adapting toward success with Scrum at Scale.

I’m told that the slides for the presentation at the link above will be posted there within the next couple of days, and possibly sooner. The slides will add a lot of detail that the main graphic doesn’t give. I will also add that there is some nuance and detail not included in the slides either. As such, I recommend try to attend one of their live or recorded video presentations to get some richer nuance…. or….

They are also presenting on this topic at Agile 2014 next week. If you’re going to be at Agile 2014, I highly recommend you put their session on your “must see” list.

The model gives a “big picture” view of Scrum in the enterprise, but it also dovetails nicely with the many years of work that Jeff Sutherland and others have put into their Scrum Patterns efforts. As you may know, I’m also a fan of this Scrum patterns concept, and you can see an example of that work on my website — Daily Scrum Patterns.

It’s worth mentioning that I have no business relationship whatsoever with Scrum Inc, so I’m not in any way incentivized to advocate for their approach.  I’m only endorsing it because I believe in the approach and in it’s future.

I suspect that this work will be a game changer in the Scrum scaling space, which doesn’t surprise me, really. It *is,* after all, coming from a company run by the co-creator of Scrum! Nice work Alex Brown, Jeff Sutherland, and Scrum Inc!

Scrum of Scrums is an event *of* the Development Team, *by* the Development Teams, and *for* the Development Teams!

Hello ScrumCrazy readers,

I’m proud to announce that my article on the “Scrum of Scrums” practice got posted on Scrum.org.

In the article I give some advice on excellence in execution of the Scrum of Scrums practice, and how the Scrum of Scrums has been misinterpreted my many to be a status meeting. It’s an event of the Development Teams, by the Development Teams, and for the Development Teams!

Please give it a look and give me feedback here or there. Feedback welcome!

Daily Scrum Patterns: The Sprint Backlog at the Daily Scrum

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

“The Sprint Backlog at the Daily Scrum” Patterns

While it’s a popular and proven practice to <View the Sprint Backlog at the Daily Scrum>, it’s a controversial practice to <Update the Sprint Backlog at the Daily Scrum>, as the updating can detract from the true objectives and focus of the Daily Scrum in some situations.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

The Sprint Backlog at the Daily Scrum Patterns:

Daily Scrum Patterns: Who Attends the Daily Scrum?

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

Who Attends? Patterns

According to the Scrum Guide, the Development Team must attend. With many teams, and especially Shu level teams, the <Scrum Master Attends>. It’s usually a good practice if the <Product Owner Attends> so that they can help the Development Team if needed, often times at <The After Party>. It’s usually not good if an <Authority Figure Attends> on a regular basis.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

Who Attends? Patterns:

Daily Scrum Patterns: Who Participates in the Daily Scrum?

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

Who Participates? Patterns

The Scrum Guide says that “the Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.” However, some practitioners think it might be ok if the <Product Owner Participates> in the Daily Scrum. Having said that, it is incorrect Scrum if a <Non Scrum Team Member Participates> in the Daily Scrum, so consider using <The After Party> to let non Scrum Team Members communicate with the Scrum Team.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

Who Participates? Patterns:

Daily Scrum Patterns: Facilitation Patterns

This blog post is part of a series of blog posts on Daily Scrum patterns.  (More coming in future posts over the next weeks).  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Notes:

Facilitation Patterns

Most teams hold the Daily Scrum as a <Standup Meeting>, but this is not required in Scrum, and some teams that are distributed feel like it’s ok to hold a <Sit Down Meeting> so long as they are faithfully executing the objectives of the Daily Scrum.

Teams just starting with Scrum might benefit from a <Close Facilitator>, so long as that doesn’t turn into a <Controlling Facilitator>. A bad practice is facilitating a Daily Scrum such that it <Turns into a Waterfall Status Meeting>.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

Facilitation Patterns:

Follow

Get every new post delivered to your Inbox.

Join 369 other followers

%d bloggers like this: