which nobody reads, and here I am with something so small.
Each card has the same structure as shown in Figure 3. At the top is the name of a work target. A work target is something to be achieved. It could be building a feature or a system, an improved process, and so on. The achievement of a work target goes through a certain number of states. The cards I have here have 5 states per work target to provide some kind of regularity. Each card has a name for the work target together with some criteria for achieving the work target state. At the bottom of the card is the state number over the total number of states, i.e. 5. The state number helps users to remember the order of the states.
Figure 3: Anatomy of a Card
The idea of using cards is not really new. Applying states to work targets is not new either. Cards have been implemented in many task tracking tools, such as ClearQuest, Mingle, EssWork, JIRA, Visual Studio Team System, and so on.
The use of cards is common with agile methods. Project teams often write down stories in a card and track the development of the story by tracking the state of the story. What is lacking is some form of guidance, or some indication of completion criteria for each state, which is normally not captured in cards. My cards fill this gap by putting check points for each state within a work target card. This interestingly opens up new ways of using the cards.
The form and substance/contents of the cards are inspired by my participation in the design and development of the Essential Unified Process and EssWork . The cards in EssWork are A6 in size (i.e. they are bigger). EssWork places more emphasis on the work target itself (which they call alpha) than on the states as their primary usage is practice composition. Moreover, EssWork still has many cards and text. So, there is still an issue of information overload even though it has been reduced drastically from traditional methods of describing processes.
I was watching a team playing Planning Poker and was concerned that the cards in EssWork could not be played in a similar way. True, the cards in EssWork help the team members understand practices, but I want to go a step further to focus on process execution. In fact, what a coach does is to help teams execute, execute better, execute faster, and execution is more about progressing things through their states. Hence my cards emphasizes work target states and their completion criteria and so they are called state-cards. You can use the state-cards for all three time scale levels I described at the beginning of this paper. You can use the cards to design your development value stream which I will also describe in this paper.
3. Dynamic Application Lifecycle Management with State-Cards
Most organizations have what is known as a lifecycle model, a designation of certain sets of criteria to meet some milestone objectives. It is useful to break down the milestone objectives into various aspects of development since they require different skill sets. As an example, the Rational Unified Process (RUP) decomposes an application lifecycle into requirements, analysis and design, implementation, test, configuration management, project management and environment. EssWork (and same with my cards) goes a step further by associating states with lifecycle objective milestones.
The problem with milestones is once a date is set for the milestone, activities beyond the milestone need to wait for the milestone to be achieved.