Diferencia entre revisiones de «Estimate Story»

De productpatterns_wiki
Saltar a: navegación, buscar
Línea 37: Línea 37:
<span id="Video_Explicaci.c3.b3n"></span><h3 style="color: rgb(128, 128, 128);" class="editable">[[Archivo:video-24px.png|left|16px|video-24px.png]]Explanatory video<span style="color: rgb(128, 128, 128);">
<span id="Video_Explicaci.c3.b3n"></span><h3 style="color: rgb(128, 128, 128);" class="editable">[[Archivo:video-24px.png|left|16px|video-24px.png]]Explanatory video<span style="color: rgb(128, 128, 128);">
<ul style= "margin-left:130px;">
*Not applicable</ul>
*Not applicable

Revisión de 16:03 29 mar 2015

Spanish.jpg Español


  • Business Story


  • Business Story



Estimate Story1.png

Development time

    • To acquire the necessary knowledge to develop the software product:
    • To create the Product Pattern: 15 minutes.
    • To apply the Product Pattern:

Explanatory video

  • Not applicable

Quality Controllers

  • None


  • Historias_Negocio.doc

Support Tools

Initial Context

This product can be used in any project that once collected the requirements of the business area for the implementation of an application, they have to be estimated by the area of technology. The estimate refers to the time in weeks, estimated it will take the full implementation (analysis, design, development, testing, integration) of a feature (story).

The most efficient estimate is based on the point estimate of story, which is the only mechanism that determines the size of a user story, ie it is the same as for any member of the group, regardless of experience on the team (junior developer / senior developer).

Story points are the relative size of each user story compared with other stories estimated by the same team.

Result Context

Two sets of stories will be obtained, some of which have been estimated by the area of technology and others that have not been estimated because they are too complex to treat unitarily or they are not sufficiently detailed. In the latter case they will be returned to the area of business for which either they will be simplified (in several stories) or completely detail.


The technology area should get an estimation of all the stories provided by the business area. The maximum estimation for each story), can not exceed three weeks.

Once the team gains experience estimating points of stories, the estimation becomes more accurate and can be performed very quickly compared to traditional estimation techniques.

Restrictions (Forces)

  • Characteristics of organizations: This pattern can be used in existing projects in any company.
  • System Type to develop This product can be used in projects in which user requirements are changing.
  • Type of Customer: It must exist or be achieved, the target area development business being involved in achieving it.
  • Heuristics for use:: It must set up meetings between business and technology where communication is smooth and has mutual trust areas. The workspace should be organized according to the guidelines of the methodology. It is important to keep food and drink to ensure meetings are relaxed.


  • Developers (2-12)
  • Director of Development Project (1)
  • Trainer (1)
  • Controller (1)

Note: The trainer and driver can be the same person.

Lessons Learned

  • The assessment should be based on a simple implementation as much as possible. Keep in mind that the property of the generated code is common to all members of the project. If stories can not be estimated answering the above premises should be returned to the area of business for the rewrite.
  • Establish meetings in which always involved the business area along with the development team (developers included).
  • Point of stories estimations more efficient than traditional methods for its homogeneous result against various team members story.

Capability Level

  • Not applicable.

Basic Knowledge and Skills


  • Knowledge of coding standard that defines the shared code ownership and the rules for writing and documenting code and communication between different pieces of code developed by different teams. Programmers have to follow the so that the code in the system look like if it had been written by one person.
  • Knowledge of the common vision of how the program in which the activities take place works.
  • It is necessary to know the complexity of each user story as well as the importance in business to make a good estimation of story points.


  • Ability to work in group. All on an XP computer contribute in any way they can.
  • Predicting what will be completed by the deadline, and determining what to do next.
  • Programming capability in pairs. Besides to generate better code and tests, used to communicate knowledge through teams.

Information Resources