As I mentioned, I received numerous questions during my presentation at the WI .NET User Group a few weeks back.  One of the them was: “Is there a way to add the subject of a user story as an explicit field?”  After probing the individual a bit, I discovered he wanted to be able to sort user stories bases on this field.  As a recap a user story is typically in the form:

As a <type of user> I want <some goal> so that <some reason>

In this post I will show you how to add the <type of user> or user story role to the user story in TFS 2010.

First make sure you have TFS Power Tools installed.  For the TFS 2010 RC, download them here.

Second, I’m going to show you how to do it using the MSF for Agile v5.0 User Story Work Item Type (WIT).  While other templates are going to be slightly different, you can use this same method as a general guideline on how to do this.

Step 1:

Open the “User Story” WIT from the Server.

Step 2:

On the Fields tab click New.

Step 3:

Setup the new field similar to that below.  You will probably want to change “MyCompany” in the Reference name to be the name of your company.

Step 4:

Still in the Field Definition dialog, click on the Rules tab.

Step 5:

Click New, select ALLOWEDVALUES and click OK.

Step 6:

In the ALLOWEDVALUES dialog continue to click new and enter the desired roles until you have all the roles you want to use.

Step 7:

Click OK back to the WIT editor.

Step 8:

Go to the Layout Tab.

Step 9:

Right click on the Column node under Group – Classification and select New Control.

Step 10:

Setup the fields similar to the following:

Step 11:

Click Save.

Your’re Done!

Your User Story screen should now resemble the following:

You will also be able to add the Story Role column to queries and sort and filter by it.

Good luck and enjoy!

Last July I posted an article on how to use a histogram to gauge how accurately you or your team members estimate.  I’ve had a few people ask me about this recently so I thought I’d post on how to create these histograms in TFS 2010.  For a quick recap on what we want to accomplish with these histograms, take a look at my July article.  You will need a process template that allows you to capture and Original Estimate and Complete Work values.  (Such as the MSF for Agile v5.0 template)  Assuming you have Excel 2007 and Team Explorer 2010 installed, go ahead and open Excel and follow the steps below:

Step 1:

Click on the Data Ribbon and Select Existing Connections.

Step 2:

You should see TfsOlapReport which is a data connection to the Tfs_Analysis cube.  Select it and click Open. (If you don’t see the connection, go here.)

Step 3:

You should the Import Data Dialog.  Change the location of the data to $A$2 as show below and click OK.

Step 4:

Drag the field “Completed Work” into the Values box as shown below:

Step 5:

Drag the fields “Assigned To” and “State” into the Filter box as shown below:

Step 6:

Drag the field “ID” into the Row Labels box as shown below:

Step 7:

Select the team member you want to look at(in this case Bob Smith) and select the State to be closed in the filter list above the pivot table.  This is show here:

Step 8:

Click the dropdown next to Row Labels, select Value Filter and click on Equals.

Step 9:

Setup the Original Estimate value you want to estimate as shown below.  (In this case we will look at the original estimate being 16 hours.) Click OK.

Step 10:

At this point you are ready to build your histogram.  You can use Excel’s Data Analysis pack to build one for you or you can build you own. I like to build my own since the Data Analysis pack charts are kinda crappy, so this is the method I will show.  Start by clicking the top-left corner of the worksheet to select the entire worksheet.   Press Ctrl-C to copy it.

Step 11:

Select Sheet 2 and press Ctrl-V to paste a copy of the pivot table into the new worksheet.

Step 12:

Select the cell directly to the right of the “Completed Work” column header.

Step 13:

Select the Data ribbon and click the Advanced Filter button.

Step 14:

Set the List Range to the all the data in the Completed Work column and select the "Unique records only” check box.  Click OK.

Step 15:

You should have a list that resembles the following:

Step 16:

Copy the values from the filter Completed Work column and paste them back into Sheet 1.  This should resemble the following:

Step 17:

Label the column data you just pasted in as “Bin” and label the column to the right of it “Count”

Step 18:

In the first data cell of the Count column add the following formula:  =COUNTIFS($B$5:$B$100,"=" &D5)

Step 19:

You will need to modify the first argument of the formula added in Step 18 to be the full range of the Completed Work column and the second argument to point the value in the Bin column.

Step 20:

Copy this formula down in the the empty cells.

Step 21:

Total you Count column.

Step 22:

Select your count column and click a bar chart on the Insert ribbon.

Step 23:

Rick click on your chart and click Select Data.

Step 24:

Select Edit under the Horizontal (Category) Axis Labels text.

Step 25:

Select all the values in your Bin column for the Axis label range. Click OK all the way back to the worksheet.

Step 26:

Select your Bin/Count table and then click the Sort Smallest to Largest button in the Data ribbon.

You’re Done!

This data should be used to help you and your team get better at estimating.  As the goal of this type of exercise is to increase our skills, I would advise against using this as a means of rating individual performance.  This can backfire by creating resistance to entering real data significantly skewing the results.

Good luck and enjoy!

First let’s start with Ward Cunningham’s definition here.  The way I explained this at MADdotNET was poor at best.  ;)  While I tend to include measures of waste in technical debt, this is NOT generally shared by the Agile community.  Simply put, technical debt is the cost (debt) from hasty software design and development.  Steve McConnell expounds on this here.  I hope this clears things up!

I presented “Succeeding With Agile & TFS 2010” for the MADdotNET User Group last night to a full house.  I want to thank everyone for the turnout and the great questions and discussions!  I’m going to try to post some articles as follow-ups to some the the questions that were asked last night that didn’t get the attention they deserve.  Some of these topics will be:  Agile Estimation, Technical Debt, Code Churn and including bugs and refactoring on the Product Backlog.  Let me know if I missed anything you want me to cover.

For those that are interested, here is the presentation:

Making the transition to Agile can be challenging for even the most seasoned organization. Having good leadership and the right tools can make all the difference. Drawing on nearly two decades of experience Chad will be walking us through methods that can be used to avoid common pitfalls and using Team Foundation Server (TFS) 2010 as an Agile platform. In this highly interactive session, Chad will demonstrate some of the new features of TFS 2010 as they relate to Agile estimation, planning, execution and measurement. If your organization is considering a migration to Agile or the TFS 2010 platform, you are encouraged to attend.

I presenting the above topic tonight at the Wisconsin .NET User Group.  Register Here!

I will also be giving the same presentation at the Madison .NET User Group on March 3rd.  Register Here!

Look for a presentation in the Chicago Land area towards the end of March.

Inspired by Michael Dubakov's article Flow. Discover Problems and Waste in Kanban, I thought I’d spend some time looking at Value Stream Analysis.

We talk a lot these days about delivering value to our clients, but many of us don’t understand the details of how that is accomplished.  Sure we understand that raw ones and zeros couldn’t be sold for the same amount as the aggregated application, but let’s take a more concise look at a couple questions?  1) How do we define value.  and 2) How do we analyze the process by which we deliver value? (Value Stream)

The first question we seek to better understand is the definition of value.  Without diving head first into an economics discussion, we can simply look at value as our client’s perceived worth of the product or service we provide.  This has a dollar figure attached to it.  While one can argue that value is also inclusive of the qualitative aspects of our product or service, it is not easily measured, so for purposes of this discussion can be ignored.  I defined a method of assigning a dollar value to SaaS features in one of my previous posts.  This method can also be used to determine the dollar value of a release, iteration, feature or task on either products or services.  With a dollar value in hand we can begin to look at answering question #2.

As we begin to examine our Value Stream, I would be remiss without mentioning the work of all the people that have contributed work in this area, Eliyahu M. Goldratt, Taiichi Ohno, James Womak, Kent Beck, Mary Poppendieck and Tom Poppendieck, to name just a few.  In Tom and Mary’s book Lean Software Development, they present Tool #2 - Value Stream Mapping which gives us a good way to visually represent our Value Stream:

If we look at the figure above, we see the typical steps that an Agile team may follow transforming an idea into reality.  There is active work that is done on the idea/feature (above the line, value add) and time when the idea/feature sits dormant. (below the line, waste)  Examining the timing of the above hypothetical flow, we can see that the overall process took 18 weeks with 11 weeks (61%) delivering value and 7 weeks (39%) of waste.  This example is a bit far fetched but is meant to provide a simple means of showing how the map works.  You may find it more useful to use days as a unit-of measure or even hours.  The point here being that you may be able to reduce your feature time to market to only 11 weeks if you could only avoid wait time.  If we assume that the feature we are developing will provide $5000 of value in the market, (to our clients) then at 18 weeks we are only delivering $278 of value a week, whereas we hit $455 a week when we do it in 11 weeks.

This can be a very useful tool for improving the productivity of your development organization but we need one more piece to make it effective.  Since we are not developing one feature at a time we need to understand the effects of multiple features flowing through our value stream.  If we only seek to optimize the flow of one feature’s flow we may do that at the expense of others.  We must look at the system as a whole and try to optimize elements that will reduce our wait time for all ideas/features currently in progress.  This is not an easy task.  You should look at the steps that are costly first and try to identify the pain points in those steps.  For instance, if there are days lost because team members are unaware of a status change, seek to implement a tool that sends automated emails on status change.

In summary, here are the steps to analyze your value stream:

1. Create a map of the steps that an idea takes from concept to delivery.
2. Measure the value-add and wait time of a number of ideas as they flow through this map.
3. Assign a dollar value to your ideas and measure your current weekly value and share this with the team.
4. If changes were already made to try to increase the flow of value, did they work? By how much?
5. As a team, come up with changes that will increase the flow of ALL ideas through the system.
6. Implement these new changes and go back to #2.

I am spending most of my time as of late providing management consulting services to my clients.  Most of them have made, or are making, the transition to Agile and often facing the same set of issues.  While I think there is no replacement for a good Management Consultant/Agile Coach, a close second is reading as much as you can from those who have successfully made the transition to Agile.  With that, I would like to present a select list of my favorites:

I’m spending quite a bit of time these days helping organizations implement Agile methodologies.  As such I hear the same set of questions and see the same set of issues over and over again.  One of the issues I see quite often is the “long sprint.”  To explain what I mean by this I’ll use a hypothetical conversation with a Team Lead new to Agile.

Team Lead: “How do you deal with the fact sprint planning and reviews take so long?”

Me: “How long is long?”

Team Lead: “Sometimes a week!”

Me: “How long are your sprints?”

Team Lead: “Usually 3-6 weeks.”

Me: “How did you determine that 3-6 weeks was a good length?”

Team Lead: “Because we couldn’t spend 2 weeks out of every month not coding!  We use longer Sprints to avoid spending so much time in review and planning.”

For those of you that are experienced in Agile, you should see a few problems here.  For now, let’s just focus on the “long sprint” concept.  The “long sprint” seems to manifest in organizations that are always sprinting.  First off, this is in direct conflict with the name sprint.  Sprints should be just that, a focused exertion of energy over a short period of time…2-3 weeks max.  So how do we solve our Team Lead’s issue with spending too much time in review and planning and not enough time writing code?  Enter the “Release.”

A Release is a means of building larger blocks of functionality in multiple Sprints. (usually 4-6)  Some Agile methodologies (XP) implement this concept directly, others do not. (Scrum)  There are many reasons to use the concept of a Release, a select few are:

• Some features just might not fit into a two week Sprint.
• Allow team to perform work in parallel to development.  In general team members can do work other than sitting in sprint review and planning sessions.  This is because these sessions are lighter weight and involve fewer people.  You simply review implemented sprint functionality ensuring it meets the needs of the stakeholder and grab the next chunk of the prioritized Product Backlog. (ok, a bit more than that, but you get the point) These two sessions should not take more than 3 days.
• Reduce the overhead of delivering software to production every 2 weeks.
• Reduce the information overload caused by releasing every 2 weeks.
• Define a delivery pace more inline with that of the organization. (the rope in the Drum-Buffer-Rope of Throughput Accounting)

The next logical question is “Do we create a Release Backlog?”  I agree with Mike Cohn in this case and would say no.  I do however, use the concept of a Release Plan or Release Roadmap.  According to Mike a Release Plan contains:

• Graph showing historical velocity.
• Prioritized Product Backlog. (including some big user stories, "epics")
• A predicted range of where we will finish. This should be either a date-range for a fixed-scope project or a functionality-range.
• Personnel assumptions. (Team members and availability)
• Velocity assumptions. ("we’ll go about half speed during December because of holidays and time off")

I would also add the following:

• A Vision Statement.  (“We want to add the shopping cart functionality and connect it to PayPal”)
• Estimated Release Value as I discuss here.

Using the concept of a Release in Agile organizations can be an extremely effective way to increase efficiency through the elimination of waste.  I will try to post more on this topic in the future.  As always, let me know your thoughts.

Further Reading:

Extreme Programming Release Planning:

http://www.extremeprogramming.org/rules/planninggame.html

Mike Cohn on Release Planning:

http://blog.mountaingoatsoftware.com/why-do-release-planning

Mike Cohn on why there should not be a release backlog:

http://blog.mountaingoatsoftware.com/why-there-should-not-be-a-release-backlog

Kelly Waters on Release Planning:

http://www.agile-software-development.com/2008/02/agile-release-planning.html

Glen B. Alleman has a great post on teams trying to use technology to solve their issues.  First tenant of the Agile Manifesto:

Individuals and interactions over processes and tools

I see supposed Agile teams doing the direct opposite over and over again.   I’ve seen really well run projects using nothing more than email and an Excel spreadsheet…and lots and lots of leadership and communication.  :)

Another book to add to the list:

Pascal Van Cauwenberghe has a review here.