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!

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

I have founded or co-founded a number of startups, worked as a consultant for Fortune 100 companies, and been an executive in large corporations.  What I’ve come to hold true is that as a company grows it experiences what Dr. Larry E. Greiner calls “growth phases.”  Dr. Greiner postulated the existence of these phases in a 1972 paper titled “Evolutions and Revolutions as Organizations Grow.” These growth phases are characterized by certain periods of growth ending in a crisis.  The duration of the crisis period can lead to what I call “growth plateaus” resulting in stalled or declining revenues.  The phases and associated crisis are as follows:

Greiner Phase/Crisis	Behavior
P1. Creativity	Creative “start-up” atmosphere.  Everyone can where any hat.  Very agile and reactive to client demands. Co-founders motivated by partial ownership.
C1. Leadership Crisis	Managers need to begin specializing.  New employees not motivated by ownership.  Need for process and controls resisted.  Co-founders still want to do everything.
P2. Direction	Functional organization structure is established.  New employee incentives introduced.  More formalized communications. First step of separating strategic and functional specialists.
C2. Autonomy Crisis	Organizational structure inappropriate.  Lower level employees feel “disconnected” from senior management.  mid-level managers start taking initiative on their own instead of following the process. Senior managers feel that they are losing power.
P3. Delegation	Concept of more autonomous business units.  Senior leadership more vision based.  Profit centers, bonuses and incentive programs used to stimulate motivation.
C3. Control Crisis	Senior management seeks to regain control of autonomous business units.  Possible attempts to centralize control.
P4. Coordination	Autonomous business units merged into groups. ROI becomes an important metric in measuring a units success. Redundant cost centers centralized. (IT, accounting, etc.)
C4. Red Tape Crisis	Programs and process begin to limit business unit’s ability to generate revenue. Innovation is dampened. Organization is now to large for formal programs and rigid systems.
P5. Collaboration	More flexibility in management.  Skilled managers effective at intrapersonal management.  Teams exhibit more self-discipline.  Focus on problem solving.  Rewards are team based instead of individual based.
C5. Internal Growth Crisis	Problem solvers exhausted from intensity of the work.  Effectiveness becomes unsustainable and cyclic.
P6. Extra-Organizational	Use of mergers, holding companies, networks of companies to sustain growth.

 

From the above, can you fit the company you are working for into any of the phases?  Are you in a crisis?  The funny thing is that employees usually seem to know if they are in a growth phase or experiencing a crisis.  Depending on the quality of the management team the crisis may be temporary or may last for years.  If you are stuck in a crisis for years, you will usually see a high volume of management turnover and hear phrases like “This has worked for us before.  It will work for us now!”  Then the revenue begins to slide. If senior management sticks to their guns, this is the beginning of the end.

What does the flipside look like?  Good leaders embrace the ability to change processes and practices if they are no longer working. (Agile Management)  Some, feeling they are only an effective as a Phase 2 manager, may choose to remove themselves from the organization completely.  According to Dr. Greiner, organizations should not attempt to bypass phases or their associated crises. Instead he recommends a few tools to managers to help them move to the next step.

 

1. Know where you are in the development sequence.
2. Recognize the limited range of solutions.
3. Realize that solutions breed new problems.

 

Here are a few good books that discuss Dr. Greiner’s concepts as well as strategies to deal with each crisis.

 

Managing Technology and Innovation: An Introduction

 

Dynamic Strategy-Making: A Real-Time Approach for the 21st Century Leader

 

Evolution and Revolution as Organizations Grow

According to the PMBOK the primary output of the Planning Process Group is a Project Management Plan.  However, there are multiple processes that can be used to support the Project Management Plan.  Here they are in order from the 3rd Edition PMBOK:

3.2.2 PMBOK Section	Name	Relevant Agile practice, process or activity
.1	Develop Project Management Plan	Combination of Product Backlog, Release scope, use cases, etc.
.2	Scope Planning	We plan scope be defining the features to be included in a release.
.3	Scope Definition	Scope is defined as the Product Backlog Items(PBI) that are included in the release.
.4	Create WBS	The Work Breakdown is done as part of the PBI to Sprint Backlog Item(SBI) decomposition.  Again, we are aiming for SBIs that are no larger than 16 hours.
.5	Activity Definition	Defined in the Product and Sprint Backlogs by User Stories and Use Cases.
.6	Activity Sequencing	Activity is sequenced in terms of greatest business value coupled with greatest risk first.  Priority should be set by dollar value as discussed here.
.7	Activity Resource Estimation	In Agile we can add or remove resources to increase or decrease velocity.  Depending upon the desired starting velocity (first few release) we can choose the team size based on estimates.
.8	Activity Duration Estimation	Discussed in the posts here and here.
.9	Schedule Development	Discussed in this post.
.10	Cost Estimation	In an Agile environment we plan to deliver continuous value by way of release and iterations. As such, there is typically continuous cost.  Based on the resource estimation we do in .7 and the purchases from .20 we can estimate cost. This has been a sub-topic of a number of my posts.
.11	Cost Budgeting	This method not used heavily in Agile.  Rely on Cost Estimation Schedule, CVE and CVP.   While Throughput Accounting is preferred over Cost Accounting PV, EV and AC can be calculated based on current release.  See PMBOK Chapter 7.2 for more information.  More on this in future posts.
.12	Quality Planning	Involve QA upfront.  Need functional test for each PBI.  Build release to QA plan.  Quality sign off mechanism.
.13	Human Resource Planning	Roles and responsibilities per Agile technique. See PMBOK Chapter 9.1 for more information.
.14	Communications Planning	Should include a plan to update stakeholders with burndowns, impediments, roadmaps, etc. See PMBOK Chapter 10.1 for more information.
.15	Risk Management Planning	Since risk is reduced in Agile, the planning process is highly simplified.  I will discuss more in future posts.
.16	Risk Identification	I will discuss in future posts.
.17	Qualitative Risk Analysis	I will discuss in future posts.
.18	Quantitative Risk Analysis	I will discuss in future posts.
.19	Risk Response Planning	I will discuss in future posts.
.20	Plan Purchases and Acquisitions	Plan for hardware, third-party software, tools, etc.
.21	Plan Contracting	Obviously required if necessary.

Now we can move on to the project execution part of this series…

In much the same way Michael Kunze coined the acronym LAMP, I propose the use of a new industry acronym for Agile. Scrum, Lean, Kanban & Kaizen. (SLKK, pronounced slick)  I have successfully used this process which incorporates techniques from all of these areas and felt it needed a name.  I also feel that it will be very useful to many of you that are already using or just beginning to use Agile.

 

Scrum – Describes the artifacts, meetings, backlog and iteration terms, etc. A good intro here. (Hat tip Ken Schwaber and Jeff Sutherland) 

Lean – Describes mechanisms for the elimination of waste, systems thinking and pull concepts. Wikipedia description here. (Hat tip Tom and Mary Poppendieck)

Kanban – Introduces the card wall, reduction of work-in-progress(WIP) and resource workflows.  Personal Kanban also useful. A great description by Kenji Hiranabe here. (Hat tip Taiichi Ohno)

Kaizen – Company and culture. Also speaks to elimination of waste using the scientific method. Using actionable items found in Scrum retrospectives, teams perform “kaizen blitzes” to improve processes and performance. Personal Kaizen also useful. (Hat tip TPS, W. Edwards Deming and Joseph M. Juran)

 

I have read numerous articles and blog posts discussing one technique vs. another and have found it amazing that very few discuss the how they compliment one another. This is what I hope to begin to do in this post.  If you would like to learn more about any of the four pieces, click on some of the links above or books below. First a picture to graphically show my thoughts.

 

Figure 1 – Scrum, Lean, Kanban, Kaizen Relationship

In a nutshell, here is what the process looks like:

1. Initial Backlog prioritized by business value.  Value drawn from market (client) needs.  This is the pull in Lean.
2. Map your value stream.  Make sure you understand how you will measure partially done work, task switching, defects, etc.
3. High level estimates.
4. Build release roadmap based on value and estimates.  Refactor if necessary.
5. Release planning session for release.  Make sure everyone is clear on the vision of the release.
6. Sprint planning session.  Limit Work-in-progress (WIP) as much as possible.  Prioritized by business value.  Make sure work is buffered and balanced. 16 hour SBI’s.  Make sure everyone is clear on the vision of the Sprint.
7. Commitment on Sprint Backlog.
8. If not already done, automated build and test environment setup.
9. Kanban card wall goes up for Sprint.  An electronic version of this on a 60” LCD works well!  :)
10. Daily Scrums review the card wall deltas.  If electronic, task cards added to personal Kanban walls.  If manual, use resource swim lanes.  How have we improved on our Kaizen item?
11. Sprint Review.  Demo new value features. What was the Throughput in dollars? Review PBI’s contained in the next sprint and verify correct priority order.  Sprint Review minutes published via email to all stakeholders.
12. Sprint Retrospective.  What are we doing well?  What could we do better?  Pick and actionable item for improvement during the next Sprint. How will we measure our improvement?  How did we do on our last item?
13. Ready for Release?  If yes, go to #14, if not go back to #6.
14. Software released to production.  Release notes sent to all stakeholders including version number, release CVE, de-scoped features, added features, impediments and any open discussion items.
15. Is the dollar value (revenue potential) for the next release greater than the cost?  If not, the project is ended or put on hold.
16. Does this project have the highest IRR of all the potential projects for this team?  If not, change projects.
17. Begin next release, go to #5.

 

While I hope to go into more detail on this technique in future posts, but for now, here are some great primer books to get you started:

Agile Software Development with Scrum (Series in Agile Software Development)

Agile Estimating and Planning (Robert C. Martin Series)

Lean Software Development: An Agile Toolkit (Agile Software Development Series)

Scrumban - Essays on Kanban Systems for Lean Software Development

Agile Retrospectives: Making Good Teams Great

Kaizen and the Art of Creative Thinking - The Scientific Thinking Mechanism

The Kaizen Pocket Handbook

I have tried using Story Points as part of my Agile estimating sessions and found them to be problematic.  Some of the problems include:

1. Introduce more complexity through the use of a unit-less measure.
2. Lack of business clarity when using story points in discussions with other executives.
3. Difficulty normalizing teams due to sizing baseline.

 

For those of you who have used Story Points, I’m sure you can at least understand the above, even if you don’t agree. 

There are a couple reasons why people want to use Story Points.  The first is to calculate velocity of a team and the second is to avoid the conversation of duration and instead focus on size of the item.  Given that, is there another mechanism that we can use to solve the issues above while still satisfying the need for Story Points?  Yes, Ideal Days with some additional metrics.

While Mike Cohn favors Story Points over Ideal Days, I am quite the opposite.  My experience has shown that if we are going to estimate things in terms of size we are better off doing so in Ideal Days.  If we use the method I suggest here and keep estimates under 16 hours then we now have a means to compare teams.  This solves problem #3 above and has been very important in the environments that run multiple teams.  Further, we can use Ideal Days in much the same way that Story Point are used.  If you use a baseline in Ideal Days along with using EBS and Proxy based estimation you can think about things in terms of size.  Your size just happens to have units attached to it now. :)  How about determining velocity?

If you attach a dollar value to each feature being developed, as I discuss here, you can now calculate some performance measurements.  If you use take concepts from both cost and throughput accounting you can calculate Client Value Earned (CVE) and Client Value Planned (CVP) to measure velocity.  CVE is the value of the completed features of the release.  Remember that we don’t realize the value of the feature until it is actually done.  CVP is simply the curve that represents where we should be from a value standpoint on any given day of the release.  Velocity is simply the ratio of CVE to time.  Here are the calculations:

A an example graph of CVP vs. CVE might look like Figure 1 with a velocity graph like Figure 2.

Figure 1 – CVP vs. CVE

Figure 2 – Velocity

You can think of the CVE graph as an inverted release burndown chart and expressed in dollar/days instead of hours.  Now if we combine this with cost accounting metrics we can have meaningful conversations with the rest of the business.  Thoughts?