Is the Project scope realistic?

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.

#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; width:500px;}
/* Add your own MailChimp form style overrides in your site stylesheet or in this style block.
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */

Thank you so much,

Luis

The post Is the Project scope realistic? appeared first on Welcome to.