Switching a classical Namics project setting to Scrum

In an ongoing classic project the question of “When can you ship feature X” is handled as part of the “Change Request Management”. At first sight the question seems very simple. However, coming up with the answer requires the following tasks:

• Firstly, all parties need to agree on “is the feature actually a new requirement?” This question alone can already be difficult since it requires a clear and common understanding of the original scope.
• Secondly, the project manager needs to organize an estimation of the work needed to build feature X.
• The project manager must have a clear overview over the current release (see picture below) – including A) the remaining resources until delivery, B) the remaining work to do, and C) the remaining time. These figures (especially remaining work to be done) constantly change and it is a challenge to keep them up to date.
• If until delivery, there are more remaining resources available than remaining work, and if these resources are larger than the work required for feature X, then the feature can be included into the release.
• ..if not, the project manager must organize more resources, postpone the delivery date, or move feature X into a later release

In practice, when answering this question, a project manager usually goes with his gut feeling – or asks the development team to make a judgement. Nevertheless, my goal was to demonstrate that the answer to this question is not as trivial as expected and it can involve considerable amount of work – especially if the project manager needs to organize more resources and if he constantly needs to keep his overview of the current release up to date.

Finally, answering this question can be stressful. It requires a project manager that can potentially push back and occasionally “say no” to the customer in order to keep a good balance of timely delivery, quality, and costs.

Now, let’s examine the question of “When can you ship feature X?” in Scrum. The second principle of the Agile Manifesto reads as follows: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

As this principle already implies, Scrum provides you with several tools that help you answering the question.

• In contrast to the classic setting, in Scrum there is no need to organize the estimation of the feature. It will get estimated during a sprint planning meeting or (optionally) during a backlog refinement meeting. Having these specific time-slots for asking questions regarding new features usually leads to fewer distractions for developers during the sprint and therefore to more efficient work.
• When the feature is estimated it is the product owner’s decision to prioritize the feature in the product backlog. If he wishes, he can include it in the very next sprint. If so, the delivery date is already clear, because each sprint delivers a increment of working software according to the definition of done.
• If the feature is not prioritized to the top of the product backlog you can still estimate its delivery date. This can be done by calculating the number of sprints it takes to deliver the feature using the average velocity. If it takes 3 sprints for example, and a sprint has a 2 week time-box, then it takes 6 weeks to ship the feature.

If circumstances change and the product owner needs to prioritize other work, the delivery date of feature X can be easily reevaluated. Whereas in a classic setting the project manager could get the blame for the delay, Scrum creates a lot of transparency and a shared responsibility between the product owner and the rest of the team to work towards a timely delivery of the new feature.

As a project manager, answering these kinds of questions took a lot of time and caused a lot of headache. Of course, switching to Scrum can have many benefits – however, in my opinion this point alone already made it worthwhile.