You have a new mention from Slack read my email — “ ”? how do you estimate when you have multiple teams working towards the same goal, but they have different development speeds and they track the work differently I thought that this was an interesting question, partially addressed to me, partially addressed to those from the Slack group. Since I was mentioned I felt that I ought to say something. I wasn’t sure though that a few sentences would do justice and I was afraid that my answer would get lost amongst other threads. Plus, I was aware of other teams battling with the same question, so I thought that I’d write up an answer. To set the context, there are three teams at play — one ‘API team’ that builds services and two ‘Front-end (FE)’ teams that build Web applications by consuming those services. The FE teams use to develop and track their work, but the API team don’t develop against those stories; they develop at a group of stories or epic level, creating their own separate tickets to track the work. The API and FE teams work in parallel. User stories The result is that the FE teams may finish their work on stories quicker but they need to before ’truly’ completing those stories. This gets reflected by a in ‘development’ until the services are finished; they will move into ‘test’ together. wait for services to be delivered to them group of tickets that will get stuck Another problem is that makes reporting tough because it appears the FE teams are not working quickly and their burnup will ‘jump’ in steps. It is easy to jump to (wrong) conclusions quickly. Even if I knew the context beforehand by spending a few days with the teams, before answering in this case I wanted to make sure that I understood the problem. I was trying to build a mental view of the situation. how to estimate really Something else was bothering me. The person who asked the question led it with ‘ ’. While I take some solace that he said that was a day and despite knowing that we spent discussing other topics not just the estimation, I was disappointed with myself that I’ve left them still puzzled about this topic. despite having spent a good half a day with Peter, I’m not entirely clear on how you do this for stories that span full stack, with component teams that all work at different speeds good What follows is an attempt to both help me and the team better answer the question. Visualising the problem first “The formulation of a problem is often more essential than its solution”, Albert Einstein. First step I took in answering the question was to truly understand the problem in hand. I didn’t want to jump straight to solutions. I saw this as a , so I thought best visualise it using flow techniques. flow problem So how does this problem manifests itself? I took the iPad and started drawing some sketches. I started by imagining how a snapshot in time would look like. The FE teams are busy working on a number of stories. They have done everything they could, they analysed the stories, developed them, peer reviewed them and tested them using mocks. Then stories got stuck and could not move to the next phase (SIT phase) because the services they required were not ready. FE Teams’ blocked stories The services are developed by the API team. They are using their own type of tickets an they batch those tickets in releases with cadences set by them. They choose to release mature services that might be used by more than one client. They feel the need to be in control of their destinies. The services for our FE teams are not released yet, blocking their stories to continue. These stories will stay in the queue for the SIT phase. Stories blocked waiting for the API team’s release When the API team releases those dependant services, then the FE teams’ stories will move to SIT together. FE stories moving together in one bigger batch FE stories moved, allowing SIT to commence I then looked at the same problem from a different angle. This time instead of looking at a snapshot we can look at the work as it progressed over time. We will represent the situation by using a Cumulative Flow Diagram (CFD), which would look something like this: A CFD representing accumulation of work per work phases over time Those stuck stories would be represented by the highlighted slice. Stuck stories appear as a ‘bulge’ on the CFD This slice highlights two aspects: the than the height of other slices, showing the accumulation the stories before they can enter SIT height of this slice is bigger a in the SIT stage indicates that bigger batches of work enter and leave SIT. While the current batch is being tested, the 2nd is already forming waiting to enter SIT, waiting for their own dependant services. ’staircase’ shape For simplicity we assume that the stories entering SIT can be tested easily; if this assumption would not stand and SIT testing would take longer, then the situation would complicate even further by resulting in an ever increasing SIT slice. This would have significant impact on the end-to-end flow. How ofter in life do we get an easy passage? partially Reporting — addressing the question At this point I was content. I was sure that I had a clear view of the situation, or at least I’m making it clear on what context I’m offering further observations. With a better view of the situation we can now ask ourselves what else can we do next? For now, lets assume that we don’t want to change the development processes, that we are happy to have the API and FE teams working in the way described above. . We can increase the visibility of the overall situation showing amongst other things the . This should put to rest at least some of the concerns of a perceived slow FE teams. Reporting is one area that can be explored two different speeds of delivery We start by looking at the Kanban systems, focusing to delimit the boundaries of (WIP) for these . This not to be confused with the concept. work in progresses systems limiting work in progress I have used in plural form because there are two work systems at play. This might not have been a conscious system design decision and might not be the way the teams look at it, but we are dealing with two systems. systems is the work the FE teams perform until their dependent services are made available to them, typically developing and testing against mocks. System 1 Boundaries of Work system 1 — from Next to INT; items depart from System 1 when they leave the ‘ IP sub-column’ of the INT phase The is a superset of System 1 and contains in addition the SIT phase. While some could define System 2 as containing only the SIT phase, I define it from to Doing it this way shows a better picture of the entire flow and offers better analysis opportunities to understand the big picture. System 2 Next SIT. Boundaries of Work system 2 — measured from Next to ‘SIT IP’ If we want to produce data driven reports, then it is important to have a system that we can measure. In order to measure a system we need to clearly define what we are going to measure, and in this context we will measure the . Once we’ve defined the boundaries of System 1 and System 2 we can look at the world using those two lenses. We can produce two reports, one for each system. work in progress Scope of the Report for System 1 is highlighted by the black border Scope of System 2 is wider To show the rate of delivery for the FE team we can create a or for Work System 1. This will show the rate at which the FE teams burn stories up to the , settling the allegation of ‘slow’ FE teams. A word of caution though. I would show this report always in the context of a second ‘big picture’ report (see below). Stating a rate of delivery covering only up to the can be miss-interpreted or miss-used in many dangerous ways. I do believe that there are other issues at play here, which I’ll explore a bit later on, but for now we are assuming that we don’t want to change any of the ways of working, we just want to improve the reporting. Burnup Throughput chart Integration phase Integration phase To , we can produce a 2nd report for the System 2. This will show a slower delivery rate compared to the other report, but a more accurate one from an end-to-end work point of view, a view that takes into account everything needed to complete work. This slower rate is due to wait time on the API team. look at the big picture Estimation — original question What about the original question — how do you in this scenario? estimate Maybe there are other more important questions to answer than this one. Hopefully visualising the problem helps identifying those questions. Here are some that sprung on my mind while I was sketching, grouped around the following : themes — is the decomposition strategy of the scope right? Is the scope sliced to suit the current company organisation or to help project to deliver value faster? Would though a different slicing optimise this project, but affect projects? decomposition strategy this other — dependencies are terrible because they slow you down. If dependencies can not be avoided by a different decomposition/slicing strategy, then what could be done to minimise the impact? Could the FE teams start the work only when the API team has completed the dependent services? dependency management — focusing on reducing the should be a much bigger goal than focusing reducing the (ok, focusing to reduce the cycle time from to and are bigger goals, but this is for another time). So the bigger, overarching question is — is the focus on designing work processes geared towards realising faster organisational goals? pursuing the right organisational goals SIT cycle time INT cycle time idea production deployment realising the benefits of those deployments The real prize is handed out when value can be realised However, I feel that once you read the above a ‘but is coming’. ‘ ’. So with this in mind, how can you help me ? In this case, my answer would be: Yes, that makes sense, and yes I can see the value in pursuing some of those questions, but I can not change all of that now, at least not overnight now I’d use some of visualisations presented here to kick off those harder, longer term discussions on debating tough questions around slicing, synchronisation of slices, organisational structures I’d report using two reports, one for System 1 and one for System 2, always shown together to estimate a release I’d produce using the FE as currency — this will reflect indirectly the wait time on the API team. Release estimations are more accurate if they model what happens in reality. a forecast based on System 2 User stories to understand the minimal capacity needed for the FE team I’d forecast using System 1. If there is a spare capacity, I might use that somewhere else. You have a new mention from Slack “ ”? It’s not a simple answer, but hopefully not that complicated either that can not be solved. I hope that this write up helps! Time to go to bed now. how do you estimate when you have multiple teams working towards the same goal, but they have different development speeds and they track the work differently

Flow

Slack

How do you estimate for teams with different development speeds?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A mechanism for building a roadmap

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

A mechanism for building a roadmap

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps