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:

• All Scrum Patterns are displayed as such: <Scrum Pattern Name>.
• All patterns currently link to the same Daily Scrum Patterns Summary Chart, where you can find out more info about each pattern.

“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:

• <View the Sprint Backlog at the Daily Scrum>
• <Update the Sprint Backlog at the Daily Scrum>

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:

• All Scrum Patterns are displayed as such: <Scrum Pattern Name>.
• All patterns currently link to the same Daily Scrum Patterns Summary Chart, where you can find out more info about each pattern.

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:

• <Development Team Only>
• <Scrum Master Attends>
• <Product Owner Attends>
• Anti-Pattern: <Authority Figure Attends>

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:

• All Scrum Patterns are displayed as such: <Scrum Pattern Name>.
• All patterns currently link to the same Daily Scrum Patterns Summary Chart, where you can find out more info about each pattern.

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:

• Controversial Pattern: <Product Owner Participates>
• Anti-Pattern: <Non Scrum Team Member Participates>

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:

• All Scrum Patterns are displayed as such: <Scrum Pattern Name>.
• All patterns currently link to the same Daily Scrum Patterns Summary Chart, where you can find out more info about each pattern.

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:

• <Standup Meeting>
• <Sit Down Meeting>
• <Close facilitator>
• Anti-Pattern: <Controlling Facilitator>
• Anti-Pattern: <Turns into a Waterfall Status Meeting>
• <Create Your Own Pattern>

Bradley Bug Chart Referenced in Awesome New Scrum Book

The Bradley Bug Chart was referenced in an awesome new Scrum Book that is now on the market.

Background

I got an email from this guy named Rich one day who wanted to talk by phone and ask me some questions about the Bradley Bug Chart. A great collaboration ensued, and I incorporated some of his suggestions into my chart. A couple of weeks later, he asked me to review Chapter 1 of this book he was writing. I have some of the highest standards around, and I’m not easily impressed, but that first chapter was extraordinary! Through that one chapter, and the conversations with Rich, I realized this guy knew Scrum inside and out. I then reviewed and commented on a few more chapters. I get asked to do unpaid reviews often, but I only spend my time on things that I think are excellent for the Agile community. I’ve spent some time reviewing another book that hasn’t been published yet, and it too, is a great one for the industry in my opinion. More on that one when it gets published.

The Bradley Bug Chart Gets Called Out

A little while later, Rich asked me if he could refer to my Bradley Bug Chart in his book(see page 277), in a section on how to handle bugs in Scrum. I was ecstatic, in part just having my work get recognition, but it was also recognition from someone I highly respected myself. It was great. I also re-wrote some of the praise that I gave Rich on that Chapter 1 review as a quote for his book. Rich also ended up quoting me a few times in other parts of the book, particularly in the chapter on “Continuous Improvement.” I’m not trying to brag here, just sharing the satisfaction of seeing some of my hard work and learning as being objectively recognized in the community.

About the Book

Here is the quote I wrote for his book:

• “Finally a book about Scrum from the Development Team’s point of view. Richard’s description of the best and worst ways to implement Scrum is priceless. The first chapter alone is one of the best descriptions of ‘Scrum done well’ that I’ve ever seen.” — Charles Bradley

I highly recommend his book for anyone working with Scrum and Microsoft Visual Studio/.Net technologies.

Here is the book:

• Professional Scrum Development with Microsoft Visual Studio 2012 , by Richard Hundhausen

Small Caveat: Rich is and was a trainer with Scrum.org, and since our initial collaboration, Rich inspired me to become a trainer for Scrum.org as well. So, while none of this was true at the time of the above events, I wanted to mention that we are now both trainers for Scrum.org. I have no financial interests in his book, whatsoever, and my journey to become a Scrum.org trainer came after my review of his book. Thanks Rich!

New User Stories Article on Agile Atlas

I recently co-authored a new article on User Stories with fellow Scrum Trainer Mark Levison. I think it’s one of the better introductory articles to User Stories on the net, and having the credibility of the Agile Atlas is great. Ron Jeffries, the co-inventor of User Stories, was one of the main reviewers of the article, so that was a little intimidating. But, he gave it high praise and only suggested a couple of minor edits. The article is now my “go-to” article on an introduction to User Stories.

Here is the article: http://agileatlas.org/gasps/article/user-stories

Other Good User Story Links:

• User Stories article on Agile Atlas (New! March 2013 – I co-wrote this one — great article if I do say so myself!)
• A User Story Checklist
• User Story Basics – The Longer Story
• To see what User Story Traps cause a lot of pain on teams, see User Story Traps
• To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready
• To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
• To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
• To see more information on grooming user stories, see:
  • What does Product Backlog Grooming Look Like?
  • Tips for Effective Backlog Grooming
• Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
• The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.
• I wrote a skit for a presentation I did at MileHighAgile 2011 that demonstrates a team doing Product Backlog Grooming for a User Story. In the skit, backlog grooming is covered pretty well, with the one exception that estimation was not covered in the skit. You can read the script of the skit here:
  • 

    Script_UserStoryUtopia.pdf

    • Download
• For good advice on how to split User Stories, see Richard Lawrence’s Story Splitting Flow Chart.
• For a good article on why to split User Stories, see Mark Levison’s Story Splitting, How Small is Enough?

Daily Scrum Patterns: Obstacle Resolution Patterns

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:

• All Scrum Patterns are displayed as such: <Scrum Pattern Name>.
• All patterns currently link to the same Daily Scrum Patterns Summary Chart, where you can find out more info about each pattern.

Obstacle Resolution

Many teams <Defer Obstacle Resolution> until after the Daily Scrum, but some teams <Allow Obstacle Resolution> if they can still avoid busting the 15 minute time-box. Having said that, it’s generally considered a bad practice if your team decides to <Save All Obstacles For the Daily Scrum>.

Some teams use <The After Party> to handle obstacle resolution and other conversations inappropriate for the Daily Scrum, and that’s probably fine unless <The After Party Defeats the Purpose of the Daily Scrum>.

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.

Obstacle Resolution Patterns:

• <Defer Obstacle Resolution>
• <Allow Obstacle Resolution>
• Anti-Pattern: <Save All Obstacles For the Daily Scrum>
• <The After Party>
• Anti-Pattern: <The After Party Defeats the Purpose of the Daily Scrum>
• <Create Your Own Pattern>

What Daily Scrum Patterns do you like to use?  Sound off in the comments.

Daily Scrum Patterns: Talk Order

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:

• All Scrum Patterns are displayed as such: <Scrum Pattern Name>.
• All patterns currently link to the same Daily Scrum Patterns Summary Chart, where you can find out more info about each pattern.
  

Talk Order

Most teams start out with a <Round Robin> approach. Teams that are distributed or are highly self organizing might use the <Talking Stick> approach. Some teams become better at getting work done if they <Walk The Items> instead, but use caution as that approach can lead to a Daily Scrum that <Turns Into 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.

Talk Order Patterns:

• <Round Robin>
• <Talking Stick>
• Controversial Pattern: <Walk the Items>
• <Create Your Own Pattern>

“Kanban vs. Scrum: The Big Smackdown” — Video now on YouTube

A few weeks ago, I participated on a panel discussion at the January meeting of AgileDenver.  Be sure you click through to the link with the meeting description before you view the videos.

Part 1
http://youtu.be/nhfhU0hqyQ4

Part 2
http://youtu.be/sfBILgeUS2w

I hope no one will take this as me having a personal jihad on Kanban, because that is not true.  I do, however, hope to inspire people to stop, and think twice, before incorrectly applying Kanban as a software development approach.  In my earlier post, I talk about why I think that is a mistake.

I also hope no one will take this as me thinking Scrum is always better than Kanban or vice versa.  Context is everything, and I simply suggest that those approaches should be applied to the context for which they were designed.  I think people should also give great deference to the creators of the respective approaches in this regard, so as to avoid what Martin Fowler calls semantic diffusion.  While Fowler calls it semantic diffusion, I have always known it more simply as the telephone game.  Luckily, we have good shepherds around like Anderson, Schwaber, and Sutherland, to remind us of the original ideas.

I also want to reassure my blog followers that I don’t intend to spend a lot more time writing about Kanban vs. Scrum.  I have some new articles that are very Scrum specific coming soon.

Related Articles:

• Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is!

• One way to handle Bugs and Production Support in Scrum

• One Way to Handle Mid Sprint Scope Changes in Scrum

Dealing with Hard to Find Bugs (Sprint Killers) in Scrum

This question was asked in an online forum(I’m paraphrasing):

> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress?  Like ones that take weeks to solve?

In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog.  Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs.  This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing.  The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software.  I would argue that this is not a sprint killer.  It is simply a fact of complex software development.

The real issue comes down to this:  Scrum transparency is trying to tell your team something.  What is it trying to tell your team?  What is your team going to do about it?

Related Articles

• The Tao of Scrum – Transparency

• One way to Handle Bugs and Production Support in Scrum

• One way to Handle mid-Sprint Scope Changes in Scrum

ScrumCrazy.com update:

• Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
• Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!