Project scheduling based on use cases or technical tasks

Question

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?

Answer 1

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:

• The nonfunctional requirements that will affect almost all stories, such as performance, should become part of the definition of done.
• Other nonfunctional requirements could become user stories or tasks within other stories.

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.

Answer 2

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.