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
* 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.