How can I learn to break down a big software project into more manageable tasks in terms of progress monitoring?

Question

One thing I constantly see project management books talk about is the necessity of a method of tracking progress. One you break down the big picture into many smaller tasks, it becomes easier to see how quickly you're moving forward, which helps organization and moral.

But how exactly are software projects broken down into smaller pieces to measure progress? Would you have tasks like, 'complete database helper class' or 'write this part of the business logic in methods'? I assume test cases are often used to determine when a task is actually completed, but how are they grouped? Is there a test case for each class, each package, each concept of business logic?

Can someone provide some examples of how a real world project was broken down into smaller, monitorable units of progress?

Answer 1

Here is what we do, and it may or may not work in your circumstances.

Depending on the size of a project we break it down into one or more features. A feature is a piece of functionality that can be shipped in isolation without dependency on other features that may be worked on or that may be planned for the future.

For each feature we break down the steps into what we call "stories". There is a lot to say about stories so for simplicity reasons let me define them as a piece of functionality that is required to deliver the feature. However a single story often cannot be shipped in isolation. Some stories may be "technical stories" which are not even visible to the end user, e.g. "Refactor/extend the upgrade process".

Once we have all stories for each feature we then estimate the stories. We use story points but you can use other metrics, e.g. NUTS (nebulous units of time), brownie points, gummy bears, or - if you must - hours of effort.

To track progress we then limit the work-in-progress (WIP). We don't want a team member to work on a dozen things in parallel. Instead we want them to focus on as few as possible and complete them faster. We track progress by counting the stories that are complete and the stories that are not yet complete. "Complete" needs to be defined. We mean by this that no further work is required by anybody in our team other than shipping the software. Also we focus on as few features at a time as possible. We believe it is better to have 3 features complete and shipped rather than having 10 features half-way complete.

As mentioned at the beginning of my answer: You may have other factors that are at work in your circumstances so a different approach may work better. However, for us this approach has allowed us to plan and track our progress in such a way that we have shipped more than 95% or our about 300 releases in the last three years on time. We have received very positive feedback from our customers on this.

Answer 2

Instead of writing my own answer, I am going to provide you with an article that, I feel, is perfect for your situation. The concept is you write a User Story than define one to many tasks associated with that particular story (think parent child). Tasks are defined in the article as something that can be accomplished in a very specific time frame.

http://blog.mountaingoatsoftware.com/sprint-and-release-planning-should-be-in-different-units

This process of breaking it down is known as Sprint Planning. This is related to the Scrum methodology in particular.

Answer 3

It all depends on what approach you are following for your Project (Waterfall, Iterative, Hybrid).

In the end, what matters is that is not as granular to create overhead for the team or so high level that it is not even useful.

The idea of rolling wave (from PMI) is a good approach that can be applied in general (adopted by the Agile community). If you start with your high level WBS (feature, deliverable, module, or any other high level) you can start by providing your best guess on completion times. This conversation goes something like this: "We should be starting Feature CX sometime in the beginning of the next quarter and should be completed by the end of the second quarter".

Then you worry about the immediate high level and break it down into very precise tasks. If you are following time-boxing (i.e. scrum, xp) then your tasks should not be larger than the period between scrums. This way your burndown charts are up to date. If you are not using time-boxing then use your best judgement to setup the tasks so that you can track them easily.

I am currently managing a project with tasks that span several weeks, with the team providing weekly updates. This is a very successful multi-million dollar project currently in its second phase of a potential 10 year run.

Answer 4

Sounds like you are looking for tips on creating a Work Breakdown Structure.

Here is a link to one template but there is a ton of information online about WBS.