Everyone wants to know how long the project will take. In this article, we will explain how to provide the manager with a precise and uncertain forecast at the same time, using the cycle time and counting stories, and give tips on when to avoid evaluation.

Celeste felt pressure. Her manager Barry wanted to make a quarterly forecast of her team’s work. The task was complicated by the fact that the group Celeste worked not on one product: Barry wanted to get a forecast for three at once. Each of them was part of a different project.

The programmers from the Celeste group did not have enough information to compile at least some forecast, especially for a whole quarter.

Celeste decided to admit to Barry and see what they would come to. She made an appointment the next day and collected the data.

The girl arrived at Barry's office at exactly 10 am. When she knocked on the door, Barry was still on the phone. He gestured for her to come in and raised one finger to make it clear: he would be ready in a minute.

She sat in the visitor chair opposite his desk.

Barry hung up and turned around: “Well, let's discuss the timing of the projects, right?”

Celeste nodded and said, “Yes. It seems that this is what can be done in such a situation. ”

Barry frowned: “It seems? I need concrete commitments. No “seems”! ”

Celeste sat comfortably:“ Barry, are you being pressured to release these three products? ”

"How did you know? - Barry shook his head. - If you listen to the guys from sales and marketing, it will be a disaster if we do not release them now. I do not know what to answer them, except that everything will be. "

“But last month you were discussing a portfolio of projects,” Celeste recalled. “I thought product A was a top priority.”

“So it is,” he said. “Both products B and C are also a top priority.”

Celeste rolled her eyes: “But you know that there can be only one top priority, can you?”

“I know that, and you know,” he said. “But my colleagues don't know.” I need a forecast that you can do - well, commitments - and then you can breathe a little calmly. ”

“What product should we work on in the first place?” Asked Celeste.

“Product A, of course,” he said. “He’s the most paid back.”

“Well, that's what we do,” Celeste said. - We will strain and release A within a month. Your task is to get these lovely people to attend our presentations every week. They should see what we do in a week. If they don't come to the demo, I refuse to give them any information. ”

Barry leaned back: “Wait. I understood about the demo. And what about the other two months? And why don't you give them any information? ”

Celeste said:“ If we worked on only one product, I could calculate the estimate based on our development cycle. For product A, we release three or four stories [code for user tasks] per week. But we don’t know the real development cycle for products B and C. ”

Barry nodded: “Why not?”

“Products B and C are scheduled in two and three months,” Celeste said. - That's pretty far for marketing. The problem is that the further the work, the less “time” the marketing department works with the owner of the product to clarify the stories. We have no idea what functions will need to be implemented in two and three months. We would have to make scientific wild-ass guess, SWAG. This is normal, I like to do it with my guys, but we need more specifics. Which is not. "

“So why won't you tell them anything if they don’t come to the demonstration?” Asked Barry.

“If it’s not important for them to observe our progress and provide feedback, then timing is not very important,” Celeste said. “They want us to commit ourselves, without giving our obligations in return.” Why should I spend time evaluating if they don’t want to contribute? ”

Barry agreed to“ sell ”a monthly timebox to managers who put pressure on him for setting timelines. Celeste will make sure that the team focuses only on product A. And she made weekly meetings for demonstrations so that the team showed its work and received feedback.

Would you be tempted to do anything else?

Timing - nontrivial work

The timing is also a job. Many teams put such procedures in their regular work schedule. However, an accurate quarterly estimate often requires more than an hour or two of work.

There are at least two problems in evaluating quarterly work. Too often, the requirements are not fully defined and, as with the Celeste team, the assessment takes the team away from the urgent work on the project.

The problem is that planning software development is not like planning a road trip. If there is more than one traffic light in your city, then you are familiar with traffic fluctuations. I live in a suburb of Boston, from where a trip to the airport can take 20 and 90 minutes. Most often from 30 to 45 minutes. This is a significant variation for a 13 km journey.

And on this trip there is no innovation. I went to the airport many times and I know several ways to get there. I have mobile apps that help find the fastest route along the way. Although some of the options are a bit more predictable, none of them can guarantee that this particular trip will be completed in 20 minutes.

The trip to the airport takes place on a predetermined route and with well-understood obstacles. But product development is another matter. This is innovation. In other words, we have not done anything like this before. If it were otherwise, then we would not have to write a new application or update an outdated system - we would use the old one.

For a reasonable assessment, we have several options. Actually three:

• You can estimate the order of magnitude. I think this is useful for the whole project. “We assume between five and nine months of work. We will learn better when we answer these questions and finish this part of the difficult work. ” SWAG is well suited for such assessments.
• You can gather enough information about the requirements and provide a reasonable estimate. The team may need to work with user stories to make a forecast with a fairly small time spread.
• There is an option to evaluate work for a short period, for example, for a week or two. It may be that the final forecast is not entirely correct. But usually he is close enough to the result so as not to disappoint the people who asked to do it.

What forecast does the manager need?

I noticed that managers often need an order of magnitude estimate. In this case, the team can make a forecast and report it as follows:

“We believe that this project will take five months with 50% confidence in the accuracy of this forecast. In the assessment of eight months, we are 80% sure. Ten months is 90% confidence. ”

This helps managers understand that there is a range of trust. If they want 100% confidence, then it may take more than 14 months.

You can use the spiral method: “We focus on the first quarter of next year. We do not know when exactly in the first quarter, but we think we can handle it. ” As the project progresses, you clarify: “We update the assessment for a term somewhere between mid-January and mid-March.” Having learned even more, say: "Somewhere in February, if there is no snowstorm." Then in January you can say: "The third week of February."

I would also recommend a range of three dates: “The optimistic date is January. The most realistic is the end of February. The most pessimistic is the end of April. ”

In any case, never give a single assessment. It tempts Saint Murphy (from Murphy's law) to tackle your project and make nasty things.

In some cases and in some teams, the customer may need additional information. Here you can discuss with him specific realizable functions to understand the uncertainties.

Use cycle time instead of rating

I don’t like forecasts for the implementation of software projects or other IT projects, especially Agile. Instead, I prefer the team to release very small stories or evaluate work by cycle time.

If you are not familiar with the terminology:

• User stories describe how a customer or user uses a product with one functional purpose (“I want to reserve a place” or “I need to publish smart city data to meet transparency requirements”). The stories differ from the look of a developer who looks at a product in terms of databases and APIs.
• Cycle time refers to the total time it takes for a team to release work on one story. This includes both active development time and downtime when work is waiting for something.

The idea is to understand the average time needed to produce something useful (history).

In the case of Celeste, she knew that a team could produce from three to four stories per week for product A. For many teams, story counting works just like other assessment methods.

If the team has never worked on a similar product, the previous cycle time will not apply to this new product. The team may not know how to refine and split up the stories in order to release several per week. In addition, she may not be aware of the status of the code and the presence of a sufficient number of tests. If your team is working on stories for more than three days, do not bother with the forecast. Count the stories and do not try to do more than usual.

When the team began to deal with the stories in one or two days, you also do not have to make an assessment. Often, a simple calculation is easier and more accurate.

Why not use speed?

You have noticed that I recommend cycle time and story counting, and not the speed of work for estimating project time. Because speed is a surrogate value.

For example, I walk every day to keep fit. I follow the same route every day, tracking my relative speed. On a nice sunny day, I walk about 5.6 km per hour. On a rainy or hot and humid day, the speed drops to 4 km / h. In the snow or ice can not go out at all, in this case, my speed is equal to 0.

I go along the same route. (Yes, it's boring, but this is my problem). Although I travel the same distance, the road takes different times depending on the conditions. Here the conditions are similar to the code base and tests of your team.

If the stories are small enough, the speed corresponds to the cycle time. But too often, managers try to evaluate for projects with very large stories. The counting will be easier: “We can finish one or two stories per cycle. Which one or two stories do you want to choose? ”

Refusing to evaluate is not a hoax.

When Barry discussed the issues with his colleagues, one of them said: “Refusing to assess the deadlines is a scam!”

Barry replied: “It’s not true. You want us to release a product, right? ”The

answer was“ Of course. Both B and C.

“The problem is that they need to be done in turns,” said Barry. - If you need product A so much, what's the point of making a forecast for the rest? We can get to work and show our progress. When we do enough, we will repeat the procedure for B and C. In addition, you will have time to clarify the requirements for B and C in order to prepare stories for us. ”

Celeste's team completed the bulk of Project A in one month. Product release B took longer - closer to two months. And since the company received sufficient income from the release of products A and B, it reduced the pressure on the release of product C.

Know what score your manager needs. Give it the way it needs. And if you have little time, get to work.

Evaluation of IT-projects: lessons

• Do not specify any specific numbers or dates. Instead, give an estimate of the order of magnitude indicating confidence in the timely release. Or offer short-term assessments based on factors under your control.
• Separate project tasks into user stories that define the functionality of the software. Then make your estimates based on the number of user stories you can process.
• Make sure you understand the requirements before making any commitments.