If there is an integration cost associated with partitioning work (Staats, Milkman, Fox 2010) then it’s worth paying attention to the way we breakdown a project’s work.
There are two dominant paradigms that I know of and work with for breaking down work; the WBS and the Product Backlog (prioritised list) but there are also probably others.
Can you help me out by nominating alternate methods for breaking a project’s work down into estimable chunks?
Subscribe to:
Post Comments (Atom)
Popular Posts
-
Due to popular demand I have aggregated some information on User Stories and created a simple template. If you feel this would be useful to... -
I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ... -
Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
-
You've heard many reasons why project fail. Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
-
The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
-
In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
-
This is a guest post by Jeff Hobbs. Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
-
In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n... -
I'm a massive Lord of the Rings fan. Every year, I spend part of my holiday vacation rewatching the 12 hours of the blu-ray extended edit... -
The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
It is possible, although you have to know the content really well, to estimate by reviewing requirement complexity. This was how we gave higher-level estimates in one of my very first projects. We gave all requirements a 1 to 5 rating (1 being simple and 5 extremely complex) and then made arbitrary durations for each level of complexity.
ReplyDeleteThere were a few requirements that were thought to be more in the 6-10 range of complexity, so those received non-standard durations.
Once we had all the estimated durations assigned, we totaled them up and divided by the number of resources available to find out total project duration.
#BAOT #PMOT Estimating using complexity is great. But the question is at what level and how do you structure the parts?
ReplyDeleteAnother option option that has come to me is a "Product Breakdown Structure" (aka a functional decomposition of the product.)
I also imagine many requirements specs group requirements by themes of various sorts (e.g. function clusters, business motivations etc.)
No other comments so far so maybe people are short on ideas. I shall tweet it a bit.
Ah, I thought you wanted conceptual, not concrete measures. Here is how we did it, using our 1-5 levels.
ReplyDeleteLevel 1 (1 day) = Changing labels, adding fields, etc.
Level 2 (2-3 days) = Minor business logic adjustments. Layout changes.
Level 3 (1 week) = Moderate business logic adjustments. Create a new screen (without business rules).
Level 4 (2-3 weeks) = New screen (with business rules). Major business logic adjustments.
Level 5 (4+ weeks) = New module with multiple, interrelated screens. System integrations.
Make sense?