![]() ![]() This extra information also helps the communication with high-level stakeholders that want to know where the time is being spent in your project. As we could now see the amount of time spent in the early stages of the process, we could also limit the WIP in columns like “Ready to UX” and “Ready to Dev”, which has lessened the time spent on those columns and reduced the total LT. This little change in the measuring process also gave us extra information on the Lead Time Breakdown chart. Measuring from “Developing” to “Done” would not satisfy the P.O.’s question, because a lot of work is done before a feature is ready for development. We believe that information is what really matters to them. ![]() One of the results that we got from those changes was the fact that now we could inform the Product Owner how much time it would take us to deliver an item. So, as explained in WIP-limit blog post, we limited the “Input” WIP, and cut off the “Refining” column, since a card would stay on it only for a few minutes (in our team a refining meeting had a very low cost to be done), and we started calculating the LT from “Input”. To do that we would need to limit the WIP of the “Input” column and start measuring the LT starting at that same column. However, we saw that we still could not answer a question: “What are the next X stories that you want to be done in Y weeks?”. We chose “Refining” instead of “Input” because, at that moment, we would only start working on a story from “Refining” on. Our team defined LT as the time a story would take to go from “Refining” until “Done”. The project had the following Kanban board at the beginning: And that is what we did in our latest project, the new Elixir Radar channel project, and we would like to share our insights on it. One of the alternatives that we found, would be to measure the LT of the whole process, from “Input” to “Done”. After the successful end of the project, we had an internal retrospective ceremony in which we’ve stated that if we had concrete information on the UX phase, we would be able to act on it earlier. The only way it was possible to spot it was based on the team’s feelings. ![]() We couldn’t see it in numbers, because it was not being measured. It was a project in which the bottleneck of the process was before the developing process: the UX designing phase. However, a project of which I was involved made me question that definition. I used to measure LT by calculating the time that a story would take to move from a “Developing” column until the end, usually the “Done” column, which means that the story is in production. I used Monte Carlo Simulation ( Forecasting software project’s completion date through Monte Carlo Simulation), limited the WIP of our process ( Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits) and now I would like to open a discussion on lead time boundaries – in which step of the process to start and end lead time (LT) measurement. In my last years as an Agile Coach, I have been testing new methodologies in order to improve them and be more agile. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |