This project has moved. For the latest updates, please go here.

Why don't you consider using AreaPath for Kanban State ?

Mar 5, 2012 at 9:35 AM


I liked your Kanban process template with this guide. I have personnally made lots of customization of process templates and some of your thoughts give me sonew ideas.

I was wondering why you just consider using IterationPath and not AreaPath to represent Kanban State ? I ask since I got an idea about that, especially with TFS11. Area seems to be central for team organization (team notion with area assignment, area security already existing in TFS2010...). In addition, it would fulfill the last requirement (allow different process flow for different team in the same Team Project).

Example :
Team Project Area
--- Team 1
------- Kanban State 1
------- Kanban State 2
--- Team 2
------- Kanban State 3

Moreover, this would also allow give rights to distinct people for different states...(to allow enforcing policies if needed...even if not fully kanban-compliant).

What do you think ?



Mar 5, 2012 at 12:57 PM

HI Clem,

Thanks for your comments.

RE: Using AreaPth for Kanban State

When we were first thinking about how we would represent Kanban states in TFS we considered several options.

* Area Path - we looked at this but there was two reasons we didn't use it. 1) People use Area Path to represent the functional structure of their projects and we didn't want to stop them from continuing with this use. 2) In a Kanban system, states are typically grouped into pairs (e.g. Development In Progress and Development Done). These pairs have a WIP limit applied across both states. The Area Path doesn't have any mechanism to add extra data (e.g. WIP Limit) so we would have had to store this data externally (e.g. in an XML file) and mapped it to the Area Paths. We wanted to store all of the Kanban meta data in TFS and allow users to modify the meta data from within the Visual Studio UI.

* Iteration Path - we looked at this and discounted it because of the same reasons as the Area Path. Another reason for discounting it was that some teams that begin to adopt Kanban, may still want to have iterations to begin with and gradually decouple the cadence of work from the cadence of release.

* WIT Workflow State - this seemed the most natural place to model the Kanban states but there were two reasons we chose not to. 1) We wanted to make it easy for users to be able to add new Kanban states, change the order, and modify WIP limits without having to use the Process Template Editor (designed for admins rather than regular end users such as project managers) 2) The same reason as point 2) above - we needed some way of grouping pairs of states and assigning WIP limits without needing to use external XML files.

* Custom WIT - this was the mechanism we chose for several reasons. 1) The Process Step WIT can represent pairs of states. 2) It can have Order and WIP Limit values assigned across pairs of states. 3) The Process Steps can be edited using the Visual Studio Work Item UI.

RE: Rights to distinct people for different states - Two of the principles that influenced our design choices was that the process should be easy to set up and be as flexible as possible. For the first release we intentionally tried to keep things as simple as possible - would be great if you could give me some more details about this scenario though?

Thanks again for your ideas and feedback.