Wednesday, October 03, 2012

Here is out little town of Nash Vegas we have a great technical community and they seem to have outdone themselves this month. There are so many great events happening I am having to negotiate with my wife to get to go to as many as I can: "I'll go see that chick-flick you've been wanting to see if I can go to BarCamp Nashville."

There is truly something for everyone, so take a look at this list and support our local technology groups by attending some of these events. Also help spread the word by Tweeting, Facebooking, shouting on street corners, body painting, or whatever!

GeektoberFest, Oct. 9th - Vaco is throwing and big "Thank You" party for the local tech community with free beer. You can't beat that. Plus they have really cool t-shirts. http://geektoberfest2012.eventbrite.com/

Nashville Technology Council's User Group Roundtable, Oct. 10th - If you help run any of the local user groups in Nashville, the NTC wants to find out help they can best support your group. This is going to be a great collaborative effort with many of the local group leaders attending. http://new.evite.com/#view_invite:eid=017AMDVWTUTCHIKMCEPB7XNQRD7M2I

Nashville .NET User Group Lecture Series, Oct. 11th - Alan Stevens, a great technologist and a friend of mine, is going to be speaking on how developers can add more value to their company and teams by "leveling up". Always entertaining and informative. http://nashdotnet.org/2012/09/october-11-alan-stevens/

Nashville BarCamp 2012, Oct. 20th - What could be better than a technical conference held at a bar? The wide range of sessions has something for everyone. A great event to meet new people and discover new ideas. http://www.barcampnashville.org/bcn12/

Tuesday, September 18, 2012

At September's Nashville Agile User Group meeting we had a discussion about how to deal with technical user stories on the backlog. There was a great deal of conversation with many good points from multiple approaches.

First we talked about what we meant by a "technical user story". We referred to stories having to do with technical activities that did not deliver any new value to the end user. Some that were brought up were things like "upgrading servers or other supporting applications", "refactoring a module to be easier to maintain", etc.

It was brought up that even though the story may not add value to the end user, it usually could be shown to have a tangible value to the company as a whole. An example was if we have a module that requires our operations folks to go onsite and manually perform some task on the servers, but we could rewrite this to be managed remotely, that could be quantified by how much time (i.e. money) we would save for the operations folks.

In that same vein it we lamented that technical people often do not communicate the value well to the Product Owner and other stakeholders so these items are left off or always pushed out (sometimes permanently). Technical user stories need to be written so that their value is clearly outlined.

At this point I mentioned that I had seen several instances online of very well respected Agile thought leaders saying never to put technical stories on the backlog. one such instance was recently on the Scrum Development Yahoo group where Ron Jeffries said:

Well that seems fairly clear, right? However if you read his entire post he directly follows the line above with:

"The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don't know the value either."

So it seemed like we were on the right track when we were talking about making sure the technical story had a demonstrable value. He goes on to say:

"If we do put code improvement stories in the backlog, we can't count the work against our Product Burndown or other progress measurements."

So it does seem that he is okay with technical stories as long as you don't count the work. This lead us down the trail of not adding the story points for technical stories to the team's velocity for a sprint. It was pointed out that Pivotal Tracker identifies these types of stories as "chores" and their points are not included in any sprint's velocity.

That sparked the debate over velocity being a metric of the team's productivity or a measure of value added each sprint. As it turns out you can find that the Pivotal Tracker folks had the very same discussion about this years ago.

I had just been talking to one of the other members about release planning right before the meeting so I added my two cents in that I prefer to not only estimate technical stories like these, but I do include them in the team's velocity because I was a metric that is a good reflection of what the team can do in the sprint to make a release plan. (I blogged about the way I like to create release plans here.) In that case I very much want to use velocity as a measure of what the team can produce.

Where we have used velocity that way we have also used a product burn up (or down) chart where we differentiated the technical stories (and bugs) from the user stories so that you could see how the team was doing as far as adding value to the user each sprint versus fixing existing stuff or working on these technical chores. To me that met Ron's criteria that you don't count the effort spent on technical stories towards an measure of progress.

Another side conversation came up when we added bugs into the mix. Do you point bugs? Do they go on the backlog with the user stories? Do fixed bugs count towards velocity? We did not get into that too deeply since that is an entire conversation in itself. Here just one instance of someone having a totally different view on how to tackle bugs, but I could easily find tons more.

When all was said and done all the attendees filled out our meeting survey which includes the questions "What did you take away from today's discussion?" Here are a few of those answers:

"Have reports that can show value delivered as well as how much work was done."

"Bugs are not really bugs until they make it into production." (Side note: this reflects part of the bug conversation where many of us talked about fixing bugs you find in the current development of a sprint immediately and tracking them more using the Sprint Backlog and our test cases. We only logged a bug into the defect tracking system if it was in released code which is what we consider any code done at the end of the sprint.)

"Learn how you want to track bugs relative to velocity."

"There are multiple ways to tackle the same problem." (You said it brother!)

"Bugs with zero story points make it difficult to track them in release planning."

As usual it was a good, spirited discussion and I look forward to our October meeting which is going to be about "Engineering best Practices in Agile." If you are in the Nashville area, sign up on our website to get notices about our meetings and upcoming events.

Thursday, September 06, 2012

In this post I want to go over the mechanics of a basic Release Plan. I am not going to get into the principles and values behind Agile release planning in very much depth, but there are some links at the end of the post to some other online resources that cover that.

This is but one way to accomplish a Release Plan and I am sure there are many other techniques out there. I have used this approach with many teams of various sizes on many projects of various sizes and complexity. I have extended it in many instances, but the basics have remained the same and served me well. I would love comments about how you accomplish this with your own teams.

The Product Backlog

To start with you need a Product Backlog. To keep things as simple our backlog will have only four fields:

ID - A unique identifier for each item in the backlog. In my example I started with 1000 so that it is not as easy to try and use ID as a default priority field (which I have seen done before).

User Story - This is just a simple title for each story and not the full story. In a more in depth backlog you would have the full story, conditions of acceptance, possibly types of categorization, etc.

Backlog Priority - This field notes the order in which the Product Owner wants the items to be delivered. This number should not have any more implied logic embedded in the number (more on that later).

Estimated Effort - The team's estimated effort for completing the item. We won't get into using Story Points, developer days, hours, etc. Suffice to say this should be a high level estimation originating from the Scrum team in your metric of choice.

Adding User Stories

There are many techniques for creating your User Stories such as story workshops, customer focus groups, etc. Again, not something I am covering here. However the Product Owner gathers them, he will record them in the backlog. Normally when we are brainstorming on stories, we simply record them in the order in which we think of them and do not try to categorize or prioritize at that point. That can sometimes hinder the flow of ideas. So you should wind up with just a list of stories. Here is a simple example of an initial backlog using Excel (the simplest tool you can use next to sticky notes on a wall).

Initial High Level Prioritization

Once you have your list some say you get the team to estimate them, but I advise you to do an initial round of high level prioritization to make sure that you maximize the team's time by looking at the ones you believe to be the most important first.

Do not make this more difficult than it needs to be. Use some simple metric with only a few values like: must, need, want. Or use 1,2,3. Or use High, Medium, Low. It really does not matter at this point and we've already discussed it too much. For my example I will use 1,2,3 since it is easy to sort in Excel.

Go down the backlog spending no more than a minute to discuss each one and give it an initial priority. Make sure everyone involved in helping with this activity knows this is not the final priority and that there will be continuous grooming sessions through out the project where it can be reassessed and changed. This will help curb the desire to analyze each item to death.

Here's our backlog with the initial priorities (NOTE: I totally made these up so try not to read anything into the actual stories.)

Initial High Level Estimates

Once we have the backlog sorted by the initial priorities, take it to the Scrum team to have them provide some initial high level estimates. At this early stage in the process it is okay to use a similar approach as we did with priority by using an easy simple metric like Small, Medium, and Large. As with the prioritization before, these estimates are not the final word and the team will be asked to take a closer look at them in the future, so try not to spend too much time on them. Good luck with that since engineers like to be precise and it is galactically hard getting them to not be. You can use any of the commonly suggested estimation techniques like planning poker or whatever works for your team.

If your team feels confident that they can use their normal metric for estimation (like the Fibonacci sequence) then let them. These techniques I am suggesting are really best at the beginning when everything is fairly high level and you really want to just get some idea of what you want to do first and how big that effort will be. As I said before, you will continuously refine the priority and estimates over the project. If your backlog is fairly large, you may want to primarily concentrate on the top most items since they should be the most valuable.

Below is our backlog now with our initial estimates.

Refine Backlog And Priorities

Now that the Product Owner has some idea of how big the backlog items are, they may want to move some items around or split up some stories. Once they have the backlog arranged in the order in which they would like them delivered, it is time to refine your metric for prioritization.

The backlog priority field should have no implied logic to it. I have seen numbers used like 1102 which meant the stakeholders wanted it delivered by February 2011. This is not a good technique as it puts pressure on the team to deliver to that date and implies to the stakeholders that is when it will be delivered. But that number is usually not based on a team's Velocity or based on any input from the team so it is a recipe for disaster.

The best way to ensure that the field cannot be used in such a manner is to always start at 1 and force rank the entire backlog. Each time you rearrange the backlog, your force rank it again starting with 1 again. After you have executed an iteration, your force rank the remaining open items on the backlog starting from 1 again. This makes it pretty hard to embed any type of logic into the number.

Here is our Product Backlog now with a force ranked priority.

Refining Estimated Effort

Just as we revisited our initial prioritization, bring the backlog back to the Scrum team to have them refine their estimates to your normal metric (unless you already did that from the start). Spend more time on the top most items since they are most likely to be played in the next few upcoming iterations. Then try to go as far down the backlog as you can (depending on the size of the backlog and your team's availability). In general your Scrum team should spend 10% to 15% of their time during a Sprint helping groom the backlog in this manner, so the items you don't get to in these initial rounds of estimating will eventually be addressed.

Now we have a Product Backlog that is force ranked and estimated to the best of the team's ability.

You will notice that some of the items on the backlog have rather large estimates. This can be due to many factors such as uncertainty, risk, pure size and complexity, etc. The Scrum team should determine a maximum size that they will allow into an iteration. Drawing this line gives the team a tool to push back on items they do not feel they could complete in a single iteration. The Product Owner should go back and break these stories up or provide answers to the team's questions to allow them to refine their estimates.

Large items at the bottom of the backlog are expected since we do not expect them to be delivered any time soon so we can revisit them later when they rise on the backlog and get closer to being played in an iteration. If you have large stories towards the top of the backlog, they need to be broken up until they are an acceptable size or moved down the backlog.

The backlog here has the larger stories moved to the bottom and the priority field force ranked starting at 1 again. For my example the Scrum team has determined that any story larger than 13 is too large for a single iteration.

Determining Initial Velocity

Velocity is the sum of effort the team completes in an iteration. At the beginning of a project you may not have any idea what your team's velocity will be. I've seen all sorts of suggestions online with algorithms and big math to figure it out based on iteration length, available days, team size, etc. Whichever technique you use, just know that you will most likely be wrong. And that is okay. After the first iteration you will have an actual velocity to start using and keep tracking it from there.

I suggest meeting with the Scrum team and talking through the items at the top of the backlog and just asking them team how far down they think they can commit to completing in the first iteration. Since this still stands a good chance of being wrong, don't spend too much time on it or hold the team too accountable to it.

For our example we will use an initial planning velocity of 15. We are also going to use an iteration length of 3 weeks and we are starting our project on 1/1/2013.

Creating the Initial Release Plan

With a prioritized and estimated Product Backlog and an initial velocity (which I like to call your planning velocity when used for release planning) we can make our first pass at a release plan. We simply start at the top of the backlog and work our way down summing the effort until we reach 15 (or right before we go over it). So if we have an item with an effort of 13 and then the next item has an effort of 3, then you should not put those in an iteration together since it would put you over you planning velocity of 15. When you reach the items at the bottom of the backlog that are too large to be played in an iteration, go ahead and stop for now. When doing this in Excel I use alternating colors to easily show the grouping of items into iterations as seen below.

Since we now have our items grouped into iterations based on our planning velocity, you can use a proposed project start date and the length of your iteration to add some dates to the groupings as well to get some idea of timing. Remember that this is very high level and is going to be constantly revisited each iteration so consider this a living document.

At this stage your Product Owner can pow wow with the appropriate stakeholders to talk about releases. Some companies release whenever they think they have enough value for their customers, so they will mainly ignore the dates at first and just see how far down the backlog they get when they reach the point where the functionality could be released to the customer. Then they can have some idea of when that may be, but of course each iteration this will be revised.

If your company does time based releases (like a regular release mid year, etc.), they can find the iteration end date before the release date. Then you can see what functionality would be completed and how much value you would be delivering to your customer. There may be issues where a group of functionality that needs to be delivered together as a unit to give the customer the best value spans your target release date and the Product Owner may have to make some tough choices.

Either way there will probably be some grooming of the backlog once this information has been hashed over. So the Product Owner may move items around, split them, combine them, etc. Anytime the Product Owner grooms the backlog, they should get with the team to have them revisit their estimates. This should happen even if they simply move some items around since some estimates may have had some assumptions on item B being easier to implement if item A was already in place and if you swap them then the estimates would need to be refined.

At this time you can choose to create a separate spreadsheet with just the items you want to slate for this upcoming release and use this as the working release plan. Then the Product Owner can move items on and off this separate list. This helps if you have a large backlog and only a subset is on the release plan. Keeping them separate can make it easier to manage them.

Revising the Release Plan Each Iteration

During each iteration, the Product Owner will continuously groom the product backlog by working with stakeholders to add, remove, refine, and prioritize stories as well as getting with the Scrum team for estimation.

At the end of an iteration you can take the Scrum team's latest velocity and use it along with your historical velocities to adjust your planning velocity. One technique is to take the lowest 3 and average them for a worst case planning velocity and then average the highest 3 for a best case scenario. Giving stakeholders these two release plans with the range will help them not cling to individual dates in them as much.

The new release plan should be shared with the team and stakeholders each iteration. As you progress towards the target release the backlog and release plan becomes more refined and more accurate. The key thing is to realize that the release plan is like an Etch-A-Sketch that you shake up and recreate at the end of each iteration based on the latest empirical evidence.

Extending the Release Plan

This simple approach works well but in most cases you will need to extend it to meet your specific needs. Be careful to not add too much and make the release plan into something it is not. That is very easy to do. Here are some common extensions I have had to make for various reasons.

Adding Bugs - I have been in many a debate about how to treat bugs when it comes to the backlog and the release plan. Many people do not like to waste time estimating the effort on bugs since there is often a good deal of discover involved before you can make a decent estimate. In those cases I have seen them put bugs in their own backlog and just dedicate a certain percentage of the velocity for each iteration to addressing the most critical. If this is your approach as well, then you will want to make sure that you adjust your planning velocity to exclude the effort set aside for bug fixes in your release planning.

Unfortunately there are many companies that come into Agile with a significant backlog of existing bugs that need to be addressed. In those cases we did treat the bugs just like stories and put them on the backlog. They were estimated and prioritized just like the other backlog items. This incurs more overhead, but sometimes is warranted if you have to get a handle on the impact of your outstanding bugs. Since the bugs are now in the backlog, you can use your normal planning velocity during release planning. If you still have a significant amount of new bugs coming in too, then you may still want to adjust your planning velocity based on your historical average of new bugs introduced each iteration. Of course if you are in this situation you obviously have a quality issue and need to take other steps to shore up your quality processes.

When we have added bugs to the backlog when then also added a field called Type that could be either User Story or Bug so that we could differentiate them when viewing the backlog or release plan. You can also then colorize that field based on the value (green for user stories and red for bugs) so with a quick glance at the release plan you can get some idea of how much of that release consists of new features.

Categorization and Grouping - Often a group of stories make up a feature and need to be delivered together for that feature to add enough customer value to release it. Stakeholders like reports on those features that show when all of the needed stories are forecasted to be released or how many items in the feature group are complete versus open. This can usually be facilitated by just adding another column called Category. The problem arises when reporting needs start to require multiple or hierarchical groupings. You can try a couple of simple techniques for these cases like, adding more category columns (Category1, Category2, etc. or MainCategory, SubCategory, etc.). You can also stick with one field and use a delimiter, but that is not as easy to filter in Excel for simple reporting.

Baselines - It never fails that someone asks to be able to see how a current release plan compares to what it looked like in the past. This can be very dangerous in that it reflects an inability to embrace change which is a major value of Agile. If you are asked for something like this I would recommend diving into why they need to know it and what they plan to do with the information. Backlogs are supposed to change and since a release plan is simply an overlay on top of the backlog, it is meant to change as well.

Business Value and ROI - Business value is sometimes mistakenly seen as the only metric for sorting you backlog. It depends on what you mean. Normally business value is something tangible like adding feature X will bring in 10% more customers in the next quarter and result in $1,000,000 in additional sales. Can't argue with that. But what if the construction and support effort to get feature X out of the door is $1,500,000?

There are also cases where you may implement a feature for less tangible reasons. You may have a very important beta customer who is very helpful in testing candidate releases. They may have a feature they really want, but it is not as applicable to your wider market. You may decide to implement this feature to maintain that relationship.

All this to say that there are many variables that go into deciding the "value" of a backlog item. I still think capturing the estimated value of an item is worthwhile, I just use it as another input to setting the overall priority of the backlog. Try to keep it as a simple metric with some tangible guidance. One example would be a rating of 0 to 1000 (1000 be the highest value). Of course people will naturally try to say everything is 1000, but that is where the guidance comes in. Maybe the range or 750 to 1000 is for items that if they are not delivered in your next release will cost your company a significant amount of market share through the loss of existing or potential customers.

Using a scale like that also allows you to do some simple Return on Investment (ROI) calculations. Divide the business value by the estimated effort, to get some idea of the actual value gained versus the amount of effort it would entail to deliver it. As I said, this is a very simplistic approach to ROI, but it is good at a high level. You can then start to see that the item valued at 1000 but with an effort of 20 has less ROI that an item at 500 with an effort of 5.

Other Resources

There are other ways to approach release planning, but the key is to make sure whatever mechanisms you decide to use reflects the Agile values your company is striving to adopt. Here are some online resources that have some additional insight on the subject.

Friday, August 24, 2012

Do you love your Product Backlog? Do you stare at it for long periods of time with a dreamy look in your eye? Does the mere whisper of its User Stories make you shiver with delight?

No?

Don’t feel bad. Most of us don’t either. A good Product Backlog is hard to find and even harder to keep up. So how can we get to the point of “Super Fantastic Product Backlog Goodness”™? (Note: I actually have no legal trademark over this phrase, but I should because it is totally awesome.) Here’s a few ideas of how to build and maintain a better backlog:

It All Starts With The Product Owner

Since the Product Backlog is the responsibility of the Product Owner, it goes without saying that their ability and availability have a significant affect on the quality of your backlog. Stay tuned for a more in depth posting about choosing the right Product Owner.

Writing Good User Stories

Size – One of the biggest problems I have seen teams struggle with is sizing stories appropriately. What size is appropriate? Well that depends mostly on your team. A good rule of thumb is that a story should be no larger than what you can finish in half a Sprint. I mostly see teams err on the side of too large since they have a hard time thinking a smaller story add legitimate value on its own.

Roles & Personas – Too many times I see stories start with “As a user..”. Who is this user you speak of? Even if this story does apply to every single use who will ever use the system, the subtleties of how they interact with he system and what they expect can be different and imply other design considerations. Be sure to spend some due diligence figuring out the various types of roles for your application and some specific personas who would fulfill those roles.

Clear Value – The third part of the User Story that outlines the benefit the user will gain from the described feature is often the hardest one to document. Smaller stories may seem to share the same benefit (and in some cases actually may), but don’t gloss over this part. Specifying the benefit of the feature helps with prioritization as well as giving the Scrum Team a better idea of why they are developing it.

Acceptance Criteria – Even more so than the actual story itself, the Conditions of Acceptance are key for giving the Scrum Team a better idea of how the feature should work when complete which leads to better estimates, better test cases, and a idea of when the feature is complete. As a story is groomed and given more detail, turning these into actual high level test cases is a good way to make sure the team has a clear vision of how to meet the needs of the users.

Grooming The Product Backlog

The Product Backlog is not an artifact you work on at the start of the project and then ignore for the remainder. You constantly groom the backlog, adding to it, reprioritizing it, and gathering the appropriate amount of detail as stories rise to the top (more on this later). If you do not spend a fair amount of time grooming the backlog it can grow into a gnarly Phil Spector-ish mess.
Most Scrum pundits proclaim a Scrum Team should spend 10% to 15% of the Sprint estimating the items on the backlog with the Product Owner. If you are running two week Sprints then that is almost 6 hours. I normally suggest breaking it up into two separate sessions so that if in the first one there are questions from the team the Product Owner has time to get answers. There is not a team I have met yet that does not initially balk at that. “Two more meetings each Sprint?!?! I’d rather spend that time coding.” You are going to spend the time either way.

When you are estimating stories, you are reviewing them together, discussing your approach, clarifying business requirements, etc. This information is invaluable for getting solid estimates and for helping to ensure you don’t get sucker punched in the middle of a Sprint due to an ambiguous story that suddenly becomes much bigger than expected. If that happens you will definitely spend more than a few hours figuring it out in the Sprint and jeopardizing other stories in that Sprint in the process.

Along with the Scrum Team dedicating time for estimating, the Product Owner must also dedicate time towards grooming the backlog each Sprint. This means holding story sessions with the stakeholders and users to get new stories, reviewing the priority of the backlog, and gathering more detail on stories that are high enough on the backlog to be slated for the next 2 or 3 Sprints. This is where the availability of the Product Owner becomes crucial. Poorly groomed stories tend to take the Scrum Team by surprise in Sprint Planning which causes them to be poorly implemented or run long.

Not All User Stories Are Created Equal

The big myth about Agile is that it allows you to “get more stuff done faster with less people”. Not true. And if someone tells you that you should punch them in the ear. Agile is supposed to help you get the important things done quickly with probably about the same amount of people. (If you disagree then you can find me and punch me in the ear.)

To ensure that you do the most important stuff first you must prioritize your Product Backlog items. This does not mean applying some business value metric and the sorting your backlog on it. The value of a backlog item has many different variables: business value to the user/company, the effort to deliver the feature, the ROI (business value divided by the estimated effort), it relation to other features that may need to come before it, and less tangible factors such as politics and solar flares. And on top of that it can change frequently. So prioritization needs to be part of any regular grooming.

A friend of mine compared a well prioritized backlog to a PEZ dispenser: you pop back the top and the delicious candy on top pops out!

Be Ready To Throw It All Away

Remember that a good User Story is a “reminder of a conversation”. It is not a specification to be strictly adhered to. Once you commit to a story and start working on it during the Sprint, the team and the Product Owner can refine it as needed. Any effort you put into detailing a Product Backlog item is potentially wasted time if done too early in the process and in too much depth. Try not to get too hung up on the story and beware of sayings like “Where does it say that in the story?”.
If the story says A + B = C, but while you are developing it the team and the Product Owner find that A + B = X then that is what it is. Do you go back to the story and change it? In my opinion, no. So where would you capture this change? In the test cases. This should be tested for in some kind of test (unit, integration, feature, whatever). Static documentation of a story can grow stale if not constantly updated and let’s face it, who the hell wants to update documentation? A test, on the other hand, verifies what the code does and as we all know “the code is the truth!”

Now Go Be Super Fantastic!

Hopefully these ideas will help you go make your own totally awesome backlog! I’ll explore implementing a good deal of these concepts in Team Foundation Server in an upcoming post.

The Daily Scrum is probably the most widely adopted mechanism in the Scrum arsenal. For good reason as it is a great communication and tracking tool for even non-Agile projects. Unfortunately people think that if they ask the standard three questions ("What did you do yesterday?", "What will you do today?", and "Are there any impediments preventing you from completing your work?") and keep it under 15 minutes then they are doing it correctly and getting the most out of this meeting.

While you might be abiding to the two basic rules above, this does not necessarily mean these meetings are beneficial. All too often the mechanism of this meeting is implemented without much regard to the underlying concepts that support it. Here are some tips and ideas around Daily Scrums I have gathered over the years I think help you get the most out of them:

The Daily Scrum is for the Team

This meeting is not for reporting to the Scrum Master or anyone else for that matter. While anyone (including Chickens if they behave) can attend, the team members are reporting to each other. Sometimes just the mere presence of a VP or other manager causes the team to feel like they are giving a status update to this person. This often results in the chicken feeling the same way and emboldens them to ask clarifying questions or start directing the meeting. It may be as subtle as them moving it along by asking the next person to start, but it can quickly turn the orientation of the meeting. I see this most often if the Scrum Master cannot be present and an attending chicken thinks someone needs to be "in charge".

To prevent this (and its hard to do when you report to these chickens in some way) try a few of these suggestions:

Remind everyone that only the scrum team and the Scrum Master are allowed to talk during this meeting. After everyone has given their updates, then questions and clarifications can be asked but everyone else can leave.

If possible, position the team in an “inner circle” and have chickens behind them outside of the circle. It is a subtle physical reminder of who the meeting is intended for.

I also think that even chickens need to be standing, but a good argument for not making them stand is to have another physical reminder.

Even with the Scrum Master present, the team should take charge in starting and moving the meeting along. When the Scrum Master does this, it can still make it feel like you are reporting to them and if the Scrum Master is also a member of management it makes it even harder to break the habit.

Use a Task Board

All too often with Scrum teams that do not use a task board for their Daily Scrums you here things like “I finished the widget class yesterday” and depending on how integrated the team is some of us may have no idea what the widget class is exactly and the fact that is it done does not give us any kind of clear picture of the progress for the User Story it belongs to. This is even less clear when you use a Agile management tool and people report things like “I finished task 24533 yesterday". If you are not intimately involved in that particular story you have no real reference to determine how it is progressing.

By using a story board you can get an idea of how a story is progressing even if you do not have any knowledge about it. By merely seeing the flow of tasks in their various states you can determine how much of it is done.

It is also easier to identify issues with stories with a task board. If someone has been reporting on the same 6 hour task for 3 days it becomes very clear there is an issue. Is there an impediment keeping them from finishing this task? Was the task originally scoped too small? Is this joker some kind of slacker? Even when people do not know they are in trouble the task board can identify the issue and them team can act appropriately.

(Note: I am planning a follow up blog post just about task boards later with more details.)

Another practice that deviates from the normal Daily Scrum rules is “walking the board”. Instead of asking the 3 questions, the team walks through each story on the backlog and says what tasks were done for each one, what is going to be started, and any impediments for that story. I was not a big fan of this at first when a client started doing it, but I think in some cases it works really well. If you do try this be careful that everyone on the team is participating since your attention is to the story and not the individual members.

Use Information Radiators

Per Alistair Cockburn an information radiator is something that show valuable project metrics that can be gained to a casual observer with a glance. This would include items like:

Sprint Burndown Chart – A graph showing the hours remaining from the Sprint Backlog for each day of the sprint. Good for monitoring how the flow of the tasks is going.

Story Burndown Chart – Similar to the sprint burndown but instead of showing remaining hours per day it shows unfinished stories.

Task Board – The task board itself is a good indication of how the project is doing per story.

Build Status – Whether you use something like Brian the Build Bunny or simply track builds passing and failing on a graph, this can alert you to problems with code quality.

Placing information radiators like these in the Daily Scrum area help the team be aware of the status of the project on a daily basis. Make sure they get updated frequently to provide the most value.

Try It, You’ll Like It!

These are just a few ideas to try and remember that what has worked for my teams in the past may not work exactly the same for yours. For a quick test to see if you are getting good information from these meetings, gather the team after one of them (away from the room so they cannot cheat and look at any of the information radiators) and ask them questions like “how is the project going?”, “are we on target to reach our sprint goal?”, and “what is team member xyz working on today?” If your team members cannot answer these questions with a significant degree of confidence then they are probably not getting the most out of the meetings.

It almost never fails as a company begins to adopt Scrum there is a mad dash of people going to Certified Scrum Master training and dubbing themselves ScrumMasters. Often this comes from a vague understanding of what a ScrumMaster actually does and the misconception that they run the project. The most likely culprits are project managers, product managers, and just plain ole managers who fear their position of authority might be usurped if Scrum is adopted to the letter at their organization. And depending on the organization, they might be right (or at least their role would change quite a bit).

At one client a would be Scrum Master told me "I coach the team like a football coach. I tell them what to do." No, the ScrumMaster is not the coach in the team sport sense of the word. If we want to equate it the sports world the almost perfect parallel is the referee. A referee makes sure the teams play by the rules and that nothing interferes with the game. Scrum Masters do coach the team in a mentoring sense, but they don't call the plays.

Let's do a quick side by side comparison:

Referee(specifically a football referee)

ScrumMaster

Enforces the official league rules of play for the game.

Enforces the agreed upon rules for the team's adopted Scrum process.

Does NOT solely dictate the rules, but contributes to their definition along with team owners, coaches, player representatives, etc.

Does NOT solely dictate the rules, but contributes to their definition along with management, Product Owners, Scrum Team members, etc.

Ensures the progress of the game is correctly communicated via mechanisms like the down marker, the score board, etc.

Ensures the progress of a Sprint is correctly communicated via mechanisms like a sprint task board, burn down charts, etc.

Ensures the timely execution of each play by keeping track of the play clock.

Ensures the timely execution of each Sprint by keeping track of the time boxed activities.

Does NOT tell the teams what play to execute.

Does NOT tell the Scrum Team was tasks to execute.

Does NOT determine the game plan for the team to implement.

Does NOT determine the features a Scrum Team will implement.

Resolves any conflicts and removes any field obstructions to allow the teams to play the best game they can possibly play.

Resolves conflicts and removes obstacles so the Scrum Team can develop

Ensures that the plays and game plan executed by the team follow the league rules.

Ensures that the tasks (Sprint Backlog) and features (Product Backlog) do conform to the agreed upon rules.

Is not held accountable when a play is botched if all the rules were followed. (Not counting bad calls!)

Is not held accountable for a team missing it's goal when all the rules are followed. (Although a good one helps find out why it was missed.)

Wears an ugly black and white uniform.

Is free to wear whatever they wish. (Within reason that is…)

Alright, so it is not a 100% perfect match, but the analogy is pretty darn close. The main point is that the ScrumMaster does not lead or control the team. The Scrum Team does that itself. The ScrumMaster does not manage the features and determine which ones the team should work on. The Product Owner does that.
So if you do intend to be a ScrumMaster, pull on your white and black striped shirt and get your whistle ready!
BTW - If you want some canned definitions for the role check out what Mike Cohn and Ken Schwaber have to say. Also, if you ever wondered what the official duties for a football referee were, you can see the NFL's explanation here.

I work in a distributed Scrum environment. Let me clarify. I work in a distributed Scrumbut environment. Half of our team is here in Nashville and the other half is in Mountain View, CA. We work very closely but as anyone who has worked in a similar situation, it is hard to be highly collaborative. I posted previously about how my company has tried to create a workplace that promotes this type of collaboration and they are dedicated to improving it.
Recently I lamented that our daily stand ups were not conveying enough information about what the team was working on and made it my mission to improve them. Since we are located in two different offices (and because some people do not recognize the value as much) we do not use a physical sprint task board. Let me be clear: a physical sprint task board is the bee’s knees and if you can use one, do so.

The Drawbacks of the Physical Task Board

So why do we not use a physical task board? First of all the ability for it to convey information to the entire team is diminished since only one office actual sees it regularly. We do use LifeSize video conferencing during our stand ups, but it is just not practical to zoom in on the task board since the viewers on the other side can’t make out any real detail.
We talked about having two boards, one in each location. This was dismissed since there would be a considerable effort for us to not only keep the two boards in sync, but also keep them in sync with our sprint backlog which we maintain in Team Foundation Server. Before you start quoting the Agile Manifesto’s views on tools, I did admit we are a Scrumbut shop and as a fairly large organization we have a great need to have this data in a digital format.
Now I saw on Jeff Sutherland’s blog a video of a team that used Jira and RFID tags on their cards for a virtual/physical task board that awesome with a capital AWESOME, but fairly impractical for us.

Setting Up the Environment

We have a great collaboration area in our office that we wanted to start using for our daily stand ups to take advantage of some of its technology. As I mentioned before there is a LifeSize video conference suite with a 55” LCD TV, remote control cameras with tilt/pan/zoom, and multiple microphones. We also have a SMART Technologies virtual white board which allows us to not only share our desktop with our counterparts in the other office, but they have a matching virtual board there that we can both interact with in real time. This is very cool for collaborative white boarding but we also wanted to try some of the various digital task board applications out there.
When we started using this space for the stand ups a few short comings in the arrangement came to light:

The video conferencing screen and the virtual white board were side by side on the same wall. This meant when someone was working with the virtual white board, they totally disappeared from the screen and we found ourselves jumping back and forth when we really tried to collaborate. We would love to have them on walls at right angles to each other, but that would require a good deal of construction work for our current space so we are looking into a mounting arm for the TV that we can tilt towards the white board.

The area is open to the rest of the office and we have very cool looking (but noisy) open ceilings. We found it hard to hear using the out of the box microphone/speaker that came with the LifeSize and the people on other side had a hard time hearing us. We had several sound dampening menageries installed that help cut down on the ambient noise, but in the end the best solution was purchasing two small microphones with long cords that could be placed deeper into the open area to pick up everyone talking better and we routed the audio from the other side through the TV speakers.

At first the video from our side was very dark due to the “cool” mood lighting the workspace designers had installed. These were soft glowing rings on the walls and hanging from the ceiling that did not provide very good lighting and gave you crazy patterns over your eyes when you stared at them too long and blinked. We removed these lights and installed brighter light fixtures. We thought this would cure our video quality problems but then we noticed that we now had very well lit video that was very fuzzy. The cool pan/tilt/zoom camera has an auto focus feature that was freaking out since the space is so open it cannot determine what to focus on. It did not help that the floor and the chairs in the area all have different, complex patterns on them. We found a sweet spot to zoom in that makes it clear but only gives you a narrow field of view. We are currently working with the LifeSize support team to find a better solution. We have also started using their stationary camera that does not have auto focus so it is clear but we have to manually move it around.

Despite some of these difficulties, these tools are great for gaining some of the individual interactions and collaboration back with a distributed team.

Virtual Sprint Task Board Software

Once we had our space setup we started using it for daily stand ups and tried using a few of the virtual sprint task board applications out there. We had a few requirements starting off:

Conchango’s Virtual Task Board

Shows tasks grouped by User Story/Bug – I think this is a must since a major purpose of the board is to convey the progress of the product backlog items you have chosen to implement during the sprint.

Zoom In/Out – We sometimes have quite a few stories and bugs in the sprint and being able to zoom out to see the big picture and then zoom in on one story is very handy.

Filter By Team – We have 5 separate scrum teams working on the project that have their individual team stand ups so being able to only see your team’s items was essential. NOTE: This for some reason did not work on our 2008 project so we had to sort the list by team and then scroll to each team’s items.

Drag & Drop Linking – If you drag a task to another user story or bug it automatically removes the previous link and creates the new one.

Cons:

Small Scroll Bars – Since we are using the application on a touch sensitive board, it would be nice if the scroll bar was bigger so we could easily touch it with our finger and drag up and down the board. Often times when we zoomed in or out the scroll bar disappeared entirely and we had to restart the application to get it back.

Mouse Over Functionality – As I stated above, when you use the application through a touch screen type scenario, functionality like the mouse over for more detail become unusable. You also have to double click on some items which for some reason is also quirky on the virtual white board screen. It would be nice if the application was geared towards a touch interface.

Filter By User – The application does allow you to filter by user, but it is not easy to select a single user since the list contains every team member with access to the TFS project and they are initially all selected and there is no unselect all feature. This should be a single click away so that when each person steps up to the board, they can quickly filter the board to just the stories they have tasks for and then easily remove the filter to see them all.

Conchango’s TFS Workbench

Pros:

Better User Interface – I like the new user interface on TFS Workbench much better than the one for the Sprint Task Board. It seems cleaner to me and easier to view the swim lanes. You can customize the colors of the notecards for each state which is a nice touch. It supports zoom in and out as well. There are also larger icons for adding, editing, etc. on the work items that make them more usable with a touch interface.

Customization– You can create custom task boards specifying the parent, link, and child types that work well for TFS 2010. This is good for viewing other items in a task board view like tests per bug/user story. Link types are not supported in 2008. You can also easily change the states shown in the swim lanes and which states show up in the “other items” bucket.

List Views – There are also list views that show work items in a list by type. It is not necessarily applicable to stand up meetings, but it is nice for other meetings where you may be editing items by batch.

More Sorting/Filtering Options – Compared to its predecessor, there are more sorting options and an easier filtering interface. With TFS 2010 it is easy to filter by team or by the higher level sprint to see all teams.

Custom Fields Supported – We don’t edit the work items from the touch board often, but when we do it is nice that our custom fields are available.

Drag & Drop Linking – If you drag a task to another user story or bug it automatically removes the previous link and creates the new one.

Cons:

Filtering By Team with TFS 2008 – Since the new SfTS v3 template uses iterations for teams, if you are using TFS 2008 there is no option for sorting by teams. This was especially hard for us with 5 teams meeting at different times but all using the same backlog.

Small Scroll Bars – Once again the scroll bars are a bit too small to easily use with a touch interface.

Mouse Over Effects – There are still a few pieces of functionality that use mouse overs which of course do not work well on a touch interface.

Filter By User – There is no support for filtering the task board by users.

Telerik’s TFS Work Item Manager

Pros:

Process Template Independent – This did not make any difference to us, but if you have multiple projects using different templates this would be a big plus.

Customization – The task board uses TFS team queries for specifying the work items in the task board which allows for some interesting customization.

Group By User – If you don’t “walk the board” by going over it by story, but rather have each user come up just to talk about their tasks, then grouping the tasks by user allows you to only view a specific user’s tasks.

Search – There is a search bar at the top of the board that will filter tasks with your search criteria in the title or description. Not super useful in a touch interface, but if you have lots of tasks it is nice to have.

Open In Separate Window – You can open the task board in a separate window without all the toolbars and menus which gives you more dedicated screen real estate.

Drag & Drop Linking/Update – If you drag a task to another grouping it will link or update the group by field appropriately. Interesting feature but not as useful for story linking due to the poor grouping interface. It is nice when grouped by user because you can drag items to other users to assign them.

Cons:

Process Template Independent – Just as this is helpful for switching between multiple templates, it makes it less useful when you use one template that is more specialized (such as the Conchango ones). There’s almost too many options and you can’t get the exact same style interface as the other applications which mirror a truer sprint task board implementation.

Group By Story/Bug – Where the other task boards show the user story or bug at the side of the swim lanes, with this application you group by parent item and they show up as collapsible headers. This was not very usable and diminished its ability as an information radiator since it did not show the status or details of stories as clearly.

Mouse Over – While the notecards did have large icons for editing and linking, they do not show up until you mouse over the item.

Small Scroll Bars – Apparently none of these apps were made with touch screens in mind!

Poor User Interface – You may question this if you look at the app because it looks nice and sleek, but there are too many options and not enough vital information clearly displayed. I found myself having to search the screen to find information I wanted. There was also no way to tell what a notecard represented (user story, bug, task, etc.) except for a color legend that you had to view in a drop down list. Most of the items were also smaller and hard to manipulate easily with a touch interface.

So Which One Do You Use?

We use the original Conchango Task Board currently since we are still hitting a TFS 2008 server on my project and we can sort the task board by team. Once we upgrade to 2010 we will most likely move to TFS Workbench.

My Perfect Virtual Task Board Application

My team sat down and talked about what we would want from the perfect task board application and here are some of our top requirements along with a screen mock up.

Show in progress tasks as "stale" if they have not been updated after a configurable amount of time.

All non-essential menus would be able to be hidden while interacting with the board but easily accessible when needed.

Most menus could be hidden an only shown when the user expands them by clicking on an icon.

If the user clicks anywhere else on the task board the menus would be hidden again.

A menu like the one used to select a current user could be collapsed to a slim bar but toggled to be expanded also.

User interface would be designed with touch screens in mind with large icons, easy scrolling, no mouse over functionality, etc.

So if someone out there is looking for a new open source project, you can build our ultimate virtual task board app and we will be eternally grateful!
If you have implemented a virtual task board, let me know how it is working for you.