= Effort Estimation =

Provide a way for users that want to calculate the depth of work needed to complete milestones with attached bugs.

'''Contact:''' RobertCollins <<BR>>
'''On Launchpad:''' [[https://launchpad.net/launchpad-project/+bugs?field.tag=effortestimation|Bugs for this LEP]]

'''As a ''' Project manager using Launchpad blueprints to track projects<<BR>>
'''I want ''' Bugs linked to blueprints to have an '''effort estimated''' field representing the person-hours needed to do the bug<<BR>>
'''so that ''' I can tell if my engineering team is overload and normalise the size of workitems in velocity calculations<<BR>>

'''As a ''' Project manager using Launchpad blueprints to track projects<<BR>>
'''I want ''' Bugs linked to blueprints to have an '''effort expended''' field representing the person-hours spent on the bug<<BR>>
'''so that ''' compare estimates with actual values in order to be able to better plan the future work<<BR>>

== 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)
 * Provide an effort expended field on bugs (or alternatively bug task)
 * Permit querying and setting those over the API
 * Be able to record the unit of the estimate, so that it can be converted as needed for comparison and calculations.

=== 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.''

  * How FogBugz does estimation scheduling - [[http://fogbugz.stackexchange.com/questions/4396/how-does-evidenced-based-scheduling-ebs-work]]

  * Effort estimation on blueprints could also be useful in Ubuntu/Linaro's process.
    - Before the work is broken down in to workitems the effort of the whole project can be estimated. While this will have a large error, it is useful for capacity planning for the cycle.
    - While workitems are being defined the estimated effort of the unrecorded workitems can be accounted for.
    - It could provide another way to estimate effort that will be expended in maintenance tasks.
    - None of these are things that could not be achieved using effort estimation in bugs.