We have a web project going on and there are several use cases and we're now busy scheduling the development of the project.

We're wondering what the best practices are about scheduling a project. Should we schedule our project based upon use cases or technical tasks? I know that scheduling based upon use cases is interesting for business because they can determine what each use case costs.

However, for developers this mindset is usually not very easy to follow (they think in technical tasks). Let's say they have a technical task "Setup Java projects", this is a requirement for each use case, so it's hard to "convert" this into the functional aspect of the project.

They can divide the story points for each use case, but let's say that business puts a specific use case on hold, then the project schedule wouldn't be correct anymore.

So my question; what's the best way to schedule a project? Should it be based upon the functional part, the technical part or both?

  • By plan, do you mean schedule? Oct 24, 2013 at 11:01
  • Indeed, I mean scheduling.
    – user7205
    Oct 24, 2013 at 11:09
  • What are your goals for the project? There are many different approaches. Each has its own tradeoffs in terms of timeliness, cost, morale, personnel turnover, technical performance, customer satisfaction, quality, etc. Start by identifying your goals. Oct 24, 2013 at 11:45

2 Answers 2


Factoring in the technical work

To schedule a project you must base it on both the functional and the technical work.

In the Scrum/Agile world you will see what you call "the technical part" referred to sometimes as "nonfunctional requirements" and sometimes as "technical debt". Everyone agrees that these need to be accounted for. However, there are different opinions on how to track them:

For example, your "Setup Java projects" can become a task in the first use case that you implement.

Even if it is technical, I would recommend that you try to explain why you need to do it to the business people, such as the Product Owner. For example, the developers may want to upgrade to the latest and greatest software version because it is cool to do so. However, when looking at the new features, the Product Owner may find that it is not anything she needs on priority. So, you might decide to skip a version upgrade altogether.


These are not your only two choices. As Mark indicated in his comment, there are many approaches. Here are some things to think about:

  1. The primary purpose of a schedule is to schedule your resources--human, materiel, equipment and tools, availability of funds, environmental logistics. Your schedule should be easy to use so that everyone involved knows what to do when and with what.

  2. Your secondary purpose is to monitor your performance. What best approach will give you the indication whether you are on track or not? For example, with tasks, you never really know how well you are progressing. A task can be 100% complete per your schedule but your product it was supposed to produce is not complete. You could have scheduled your painters and the availability of paint and brushes and other materials to cover two coats of paint. At the end of two coats, your wall is still not finished as it requires another two or three coats. How do you reflect that on your schedule? Your resources have gone. Now what?

  3. Managing your schedule requires costly effort. What do you have available to do these tasks? Your choice in the approach to derive a schedule is constrained by what you have available to work your schedule. Make it too complex and you have little to no availability of scheduler and tool resources, your schedule will become useless quickly.

  4. What makes sense to you in order to manage your project? While I wrote above you want to ensure all stakeholders understand your schedule, you really need to ensure you understand it as the PM so that you can answer all the hard questions that will come your way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.