Luis Gonçalves – Blog

Agile, Scrum, Retrospectives, etc.

Is the Project scope realistic?

project-scope-statement

Project Scope

project-scope-statement

Project scope is an interesting topic. During last several weeks, I have been involved in planning the release of our new product. This post explains the way I worked with the C level, and how I helped them to understand whether the project scope was realistic. I also explain how we executed the release plan for this particular project.

In our case, the release date was fixed. Ultimately, we had a date we could not miss. Otherwise, our company would encounter immense problems. Knowing this, we found it necessary to understand whether the project scope was realistic enough to proceed with the plan. When I had the opportunity to talk with the CPO, he explained that we needed X amount of features. Therefore, they would need my help to determine if it was possible to deliver all of those features on time.

First, I needed to examine the historical data, in order to define the project scope. Because, if I study the data, then I can find out how many stories we were delivering, and, at the same time, map those stories into features. Then, I would have a general idea of how long it would take us to deliver all necessary features. Now, you may be thinking, not all features are the same. So, how can I choose this approach?!

Yes, you are right, the features are indeed different. Yet, my experience tells me that features converge, and the number of features delivered per sprint, or per month, gives us a good knowledge base. We can use this to track where we will end up in the future.

Then the problem started, I analyzed the old data, and realized that we did not have any relationship between features and stories. We only had information for feature releases. As a result, how could I figure out where we would end up, if all of our previous data was useless?

Next, we decided to request the top priorities from Product Management. We asked them to identify what the most important features of that release were. This way we ensured that we were always working with the highest priority features.

Afterwards, we asked the teams to break those particular features into stories. It is important to note, we only asked for the number of stories that would fill the first two sprints. More would have been a pure waste of time. Based on previous knowledge, after two sprints all stories will be different.

With this approach, we were able to calculate the number of stories each feature has on average. Then, we could record the previous speed of the teams, and predict where we should end up, more or less. For example, we determined that each feature contained five user stories, and each team was delivering five stories per sprint. Therefore, each team could deliver one feature per sprint. Also, in this particular project, we had five teams, which means, we could deliver five features per sprint.

In our initial release plan, we had approximately fifty features. This meant we would need ten sprints, in order to deliver all the required features. Now, we had a general idea as to whether the project scope was realistic or not. With a fixed release date and the known rate of features, we could predict where we would finish up.

This is a complex topic! Many people prefer a different method, but I must say, this method has worked quite well for me. It has proved to be an excellent way to determine whether the initial project scope is realistic.

Of course, this is just the beginning. Later, we will create a Release Burndown Chart. This is where we can track the progress towards our goal every week. This close examination of the weekly course gives us the precise information we need, in order to establish where we will end up. Then, with this information, Product Management can always see where we are, and can to remove features accordingly, to accommodate the release date.

I hope you enjoyed this blog post. Vasco Duarte also has some really interesting information about this subject. If you want to follow his blog, you can find it here.

If you liked this article and you do not want to lose future ones Sign In to the mailing list below.

Subscribe to our mailing list

* indicates required Email Address * How did you find me Name

2 thoughts on “Is the Project scope realistic?”

  1. Chris Murman says:

    Great thoughts Luis, although I’m not sure this addresses the question in the headline: is the project scope realistic enough?

    I face this question with every app my teams make for clients. Often, scope is determined by perceived value — meaning they are paying X amount of money for work so a certain amount of work must go into it (meaning hours burned). Business decisions may determine how realistic scope is, meaning they may already might be selling or marketing the product. If scope is considered to be more valuable if it has more features in the given time frame, then the value of an individual feature isn’t as important as the value of the release overall.

    Maybe I’m just wary of this topic since scope is never realistic from the team’s perspective. :)

    1. Hi :)

      Thanks for the time that you took to reply :)

      Maybe I did not explain well enough :) I think this method can tell you in a rough way if the scope is realistic or not :) For example in this case our release needs to be in September and with the current scope we are going to land in August next year :D You can already see that we can have a feeling if its realistic or not :)

      But something that I think i did not mention was the fact that we ALWAYS ALWAYS work in the features that bring the most value, allowing us to create a MVP on time to release in september :) Its difficult to explain in here but I hope that I am able to pass my idea :)

      Luis

Leave a Reply

Your email address will not be published.

*