Effort Estimation
Provide a way for users that want to calculate the depth of work needed to complete milestones with attached bugs.
Contact: RobertCollins
On Launchpad: Bugs for this LEP
As a Project manager using Launchpad blueprints to track projects
I want Bugs linked to blueprints to have an effort field representing the man-hours needed to do the bug
so that I can tell if my engineering team is overload and normalise the size of workitems in velocity calculations
Rationale
Linaro report that they are not able to achieve their (fairly lean) project management needs using Launchpad blueprints. While Launchpad is not a project-management tool, having complex projects in Launchpads is expected because we do track defects and wishlist items - we should either integrate really smoothly with an external project management facility or supply a sufficient API and data store that a good project management facility can be layered on top. Layering is the current approach taken by Launchpad users, and the extra data this LEP requests will allow the layered tools to be easier to use, cleaner, and make better use of Launchpad primitives like bugs.
Stakeholders
Joey Stanford @ Linaro, representing their project management team.
Constraints and Requirements
Must
- Provide an effort estimate field on bugs (or alternatively bug task)
- Permit querying and setting that over the API
Nice to have
- Searches for bugs which use the effort field - e.g. an in progress bug which has 2 days of effort remaining could be search for as 'expected by $date'. Or something.
Must not
Make the LP bugs UI fugly.
Out of scope
Workflows
What are the workflows for this feature? Even a short list can help you and others understand the scope of the change. Provide mockups for each workflow.
You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.
Success
How will we know when we are done?
The Linaro project managers will be able to generate estimated durations (rather than simply a count of work items) for their burn down charts.
How will we measure how well we have done?
A post implementation check with Joey Stanford to assess the effectiveness of the change.
Thoughts?
Put everything else here. Better out than in.