A Great Link for Patterns on How to Hold a Great Agile Standup Meeting

I never cease to be amazed by the great work that Martin Fowler has on his web site.  (In all fairness, though, this post seems to be mostly from Jason Yip).


“It’s Not Just Standing Up: Patterns for Daily Standup Meetings”


Also, while you’re here, you might want to take a look at one of my older blog posts:

“Bad Smells of the Daily Scrum”


As usual, all feedback welcome.

P.S.  Have you noticed that I’ve been posting a lot more lately?  One reason is that I’ve had more time lately to write, and another reason is that I figured out that WordPress now has a feature that allows me to schedule when the posts are to be delivered, so I can just queue them up! Sweet!


One Way to Handle Bugs and Production Support in Scrum

This article has been updated and republished here.

Steve Denning – Rattling the Cages of Command and Control Managers on Forbes.com

Are any of you following Denning’s recent articles on Forbes?  He is “killing it” for Agile.

I especially like the bottom link…





Anyone have opinions on Steve’s work?  I’m not familiar with it other than passing references to his book.

A User Story Checklist

Sometimes it’s difficult to determine if something is a User Story or not.  Not everything a software team does is a User Story.

In my other article, User Story Basics , I talk about the definition of a User Story.  I will use that definition to make a checklist of characteristics a User Story must have.

  1. Does the story describe new or changed functionality in the system under development?
  2. Is the functionality primarily of value to a stakeholder playing a role other than the role of “developer on the development team for the system under development”?  Said another way, is the functionality primarily of value to a Non Development Team stakeholder?
  3. Is there a fairly unique written description of the story?  (This can be just a couple of words, like a title)
  4. Have conversations about the story, that clarify story details, taken place?
  5. Does the story have acceptance tests that convey and confirm when the functionality of the story is complete, correct, and present in the system under development?

If you cannot answer “Definitely, yes!” to all of the above 5 questions, then it is almost always… NOT a User Story.

With respect to Question #2, I tend to define ¨developer” fairly broadly, like Scrum does.  From the Scrum Guide: “[Development] Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or data base design…”.  On some development teams, people who play a role of developer also play a role of “product support member” for the system under development.  In this way, sometimes User Stories describe functionality that is important to someone doing production support.  Other than this one exception, though, functionality and features that are primarily of importance to developers are almost always not considered User Stories.  On the other hand, there is nothing wrong with a developer suggesting some functionality to a NDT Stakeholder, and/or convincing a NDT Stakeholder that some functionality will be primarily of value to that stakeholder.  If that stakeholder agrees, then you can re-classify that functionality as a User Story… so long as you can say “Yes” to all of the other questions above.

A question that often comes up is, “Should Fixing a bug be represented as a User Story?”  The answer is, it depends.  The only question we might have trouble answering “Yes” to is #2.  The first thing you should ask is this: What (already delivered) User Story Acceptance Test(or tests) fails due to this bug?  If you can’t point to one specific acceptance test, then it’s probably a missed acceptance test(meaning one was overlooked when the story was originally implemented) or a legacy bug(a bug introduced before you adopted User Stories), in which case, the bug should almost always be represented as a new User Story.

Best Practice – Minimize Manager input in Retrospectives

One of Scrum’s main tenants is about self organization. Self organization is difficult enough to achieve on its own, especially with a new Scrum team or a team who has members who are new to each other on it. In the context of this article, when I say “Manager”, I mean someone who has a large amount of input in determining the company advancement (performance reviews, raises, promotions, etc) of any individual on the Scrum Team. It could be someone a team member reports to, or it could even just be a supervisor or team lead. Sometimes a Manager plays a Scrum role like Product Owner or Scrum Master. I’m *especially* talking about those managers. Those managers should not attend the retro, or at the very worst case, should attend only a minor part of the retro(See “Strategies” below).

It should be obvious to Managers (though often it is not), that honest genuine feedback about how to work better as a team is very hard to get with a Manager in the room. Every time a person opens their mouth, they are taking a political risk if their manager is there, and that is not a safe environment for true collaboration and innovation. Managers, if you don’t believe me, try the strategies below for 3 sprints, and judge the results for yourself. You, as a manager, have every right to ask the team, one day after the retrospective is over, for their plan of action on improvements. I say one day after because I’d strongly prefer that you not come into the room where the retrospective is being held once it is over. Often times there are things on whiteboards that you may or may not understand, and again, that becomes unsafe.


  • Appoint a Facilitator
    • If a Manager does not fulfill a Scrum role, then the team should appoint a facilitator, preferably one totally independent of the team. Good candidates for this are Members of other teams with good facilitation skills and/or Scrum Masters from other teams. As a last resort, if that’s not possible, then appoint someone on the team who would be a good “neutral” facilitator. It’s ok if that team member also participates in the retro, but you can leave that decision up to them. Have the team prepare any specific feedback that they have that involves the Manager in their private retrospective, and present that feedback to the manager as a team. (Remember that they may have no specific feedback for the Manager, but often they will ask the Manager’s help in implementing Retrospective Action Items.)
  • Part-Time Retrospecter
    • In the case where a Manager(or team lead) plays one of the Scrum roles (PO, SM, or developer), have the team, as part of their retro without the Manager, decide which topics will be discussed with the Manager. Any topic that is not chosen for discussion is not discussed with the Manager. In particular, any feedback the team has for the Manager in their Scrum role, have the team present that as a unified team rather than individuals. Also allow the Manager to raise their own independent topics, of course. If the Manager strays into one of the topics that the team has not chosen to discuss, then inform the manager of the outcome of the team discussion.

Excluding the Manager from the Retrospective is not an attempt to usurp the Manager’s authority or anything like that. It is to create the safety and experimentation that is required for great innovations to occur. The Manager still has a very important role to play — see The role of Managers in Scrum .

Related advice

Related articles

I Mostly Hate Software for Managing Scrum Teams

Update February, 2012: I’m currently seeking my next engagement as a Scrum Coach or ScrumMaster, so please contact me (You can use the “About” tab above) if you know of an opportunity.

I often get asked to evaluate a particular Scrum tool or to compare the relatively value of one to another. To be honest, tool evaluation is not something I spend significant time on. Most teams I coach have little choice about which tool to use, so I usually just a) try to encourage them to use more manual techniques and b) help the team adapt the tool usage to their optimum performance/usage, which sometimes means no usage.

I hate the tools

Ok, hate is a strong word, but I’m generally anti-tool when it comes to managing Scrum artifacts and data. I strongly prefer more manual techniques (Scrum Boards, sticky notes, story cards, white boards, wikis, etc).

Reason 1: Tools often hurt more than they help. (Decreases Productivity)

The vast majority of the time I have seen Scrum teams extensively using a tool, it is wasteful or aids in creating poor habits. It’s pretty hard to justify spending money on a tool that decreases overall productivity. I’m amazed at how many companies do this. I also believe that most of these tools have a huge amount of bloat in them, and thus the bloated features either a) obscure the needed features or b) waste a lot of time with very little ROI in terms of value.

Reason 2: They usually encourage bad habits, or at least enable bad habits. (Decreases Transparency & Productivity)

  • Bad Habit # 1: The worst habit they encourage is that they often obscure transparency by hiding data inside the tool that has to be …started up, logged into, and menu driven to the point of wanted info. Transparency in Scrum is VERY important, which is why I favor more manual techniques. This obscurity is extremely widespread as it affects the product backlog and/or stories, sprint backlog tasking, teamwork, optimizing with a burndown chart or other sprint progress monitor, etc. Transparency aids in inspection and adaptation, so the converse is also true: obscurity detracts from inspection and adaptation and thus, detracts from the empirical nature of Scrum.
  • Bad Habit # 2: They discourage mis-use of good techniques. For instance, in many tools, there is no direct support for story tests/acceptance tests directly with the User Stories themselves. One tool at least allows some basic html formatting and tables so that you could put in some concrete examples like those that are encouraged by the “Specification By Example” technique. However, that tool’s HTML formatting is very clunky and far inferior to any decent wiki.
  • Bad Habit #3: Having a tool encourages double entry. I’ve seen teams where, because they were forced to use a tool but also wanted a good Scrum Board, had to do double entry of the same information. Giant waste of time.
  • Bad Habit #4: A tool encourages mis-use of metrics created by Scrum related data such as velocity. Many managers and executive types will try to do draw incorrect conclusions from data tracked in such a tool. Yet another giant waste of time. The managers and executive types should instead be focusing on whether the users of the system are getting value out of the features that are being provided. While some management has a responsibility to focus on productivity in software development, micro-analyzing the Scrum data is not a good way to do this.

Reason 3: The development team usually has the tool forced upon them, or usually has no choice but to use a particular tool. (Decreases Self Organization)

Besides the normal effects of top down mandates (poor adoption, minimal ROI, etc), the elephant in the room created by mandating tools is that it greatly harms self organization on a Scrum team. Mandating particular tools or tool usage is just another form of command and control management. To achieve Scrum’s benefits, self organization is absolutely vital, which means, when it comes to tools, the team should be able to make their own choices.  I want the team as a whole (and preferably not the ScrumMaster at all) to create, maintain, own, love, and care for their own artifacts.  Having said all of this, it’s perfectly acceptable for management types to try and organize company strategy around goals and timelines — I just don’t believe that Scrum software tools are a good way to do that.

In Conclusion…

There, I said it… I’m generally anti-tool for Scrum artifacts and data.

In a future blog post, I intend to talk a little about some special contexts in which I think tool usage is ok, and about my general views as to the kinds of tools that I like. Teams where multiple members are working mostly remote is one exception to my generally anti-tool stance. I’ll talk more about that in the future post.

Best Practice – Make Retrospective Action Items Highly Visible

Here is how I define a Best Practice:

  • Best Practice -a practice that is good in almost all contexts and almost all team situations.

Many teams talk a good game on making changes to their development process, but fewer actually make those changes. Therefore, it is a Scrum Best Practice to make Retrospective action items highly visible to the team, usually on or very near the Scrum Board.

The visibility technique employed will be highly dependent on the team. Consider some of the following methods, or come up with your own!

  • List them in big letters on a Scrum Board
  • Create Sprint Backlog Tasks for action items and make sure they get to “done”.
  • Do this: Best Practice – Review the Action Items from the Previous Retro in the Current Retro
  • On certain days (Like Mon/Wed/Fri, Tue/Thurs, even, odd, every day, etc) in the Daily Scrum, have a team member pick a retro action item to talk about and have them talk for 30-60 seconds(time-box) about the action item. They can talk about the state of the item(announce completion!), why the item is important, give the person who came up with it or completed it praise, or even something like what life will be like once that action item is completed.
  • On random days, offer a prize for anyone who can list a retrospective action item that is supposed to be completed in the current sprint. The prize can be very small or token, maybe as simple as candy or another desirable treat.
%d bloggers like this: