This is a little bit about how work at where I work works.
Visualisation of work
Kanban. Is the system used to visual the work. It includes who is involved, what they are involved in, what state work is in and whether there are things getting in the way. The currency of the work is a story. The more stories completed, the richer everybody is. Flow is everything.
The currency of work
The vessel of all work is a story. Stories have a size, small (S), medium (M) or large (L). The size of a story is dictated by the complexity of the work involved. This is often based on the number of systems that will need to be changed to complete the work.
What does a story look like?
There is no set definition of what a story is (perhaps there never will be although it would probably be a good idea). The level at which a story is created varies. Some of the experiences differing levels of story have provided are:
One project had stories focused on the technical activities required to get the work done. They were very much like tasks. Stories at this level moved through the board quickly, this built momentum. It worked well for technical people. It did not work well for non-technical people. The board was flooded with stories that made little sense to business people. However good it might have been for the technical team, not having the business understand the state of the project is not a good position to be in. Especially when a goal of the project is to increase the level of participation of the business in the development of products.
Another project had stories written at a much higher level, one where they would provide some real value to the Product Owner (PO). There were far fewer stories and each story was much clearer about what was being delivered. This approach worked much better from the point of view of looking at the board and understanding the state of the project. Business people were much more bought in. This is a very good thing. However, it was not all roses and sunshine. The major loss was the flow of stories through the board. The board stagnated. How to improve on this is an on-going concern. Probable solutions revolve around another board, a ’technical' board, however, this has its’ own challenges.
Free flowing
One of the goals of Kanban is to increase the rate at which stories flow through the board. This is referred to in two ways - cycle time and lead time.
Lead time
This is how long it takes a story to get across the entirety of the board. From initial state to end state. It is useful to see how long an idea takes to go from inception to realisation. Often used by the business.
Cycle time
This is how long is takes a story to get to done i.e. from the time it leaves the backlog until it reaches the end state. Provides information on the time it takes to do the work. Used by the team doing the work.
Why should anybody care about lead and cycle time?
There are many reasons to care about lead and cycle times. My number one reason is, the smaller the time it takes to get something to the end state (which should really be the production environment) the quicker the product can be iterated.
The quicker the product can be iterated, the quicker the wants of the users of the product can be met, the happier those users can be made, the more users there will be. Ultimately ending in the beating of competitors whilst providing the best product possible, built based on the needs of the users. Win, win.