{"id":1476,"date":"2023-05-24T08:32:43","date_gmt":"2023-05-24T06:32:43","guid":{"rendered":"https:\/\/www.risc-software.at\/fachbeitrag-schaetzen-in-agilen-projekten-mit-story-points\/"},"modified":"2025-05-07T10:21:27","modified_gmt":"2025-05-07T08:21:27","slug":"technical-article-estimating-in-agile-projects-with-story-points","status":"publish","type":"publication","link":"https:\/\/www.risc-software.at\/en\/technicalarticles\/technical-article-estimating-in-agile-projects-with-story-points\/","title":{"rendered":"Estimating in Agile Projects with Story Points"},"content":{"rendered":"\n

Cost estimation of agile software projects<\/h2>\n\n\n\n

by DI (FH) Andreas Lettner<\/h3>\n\n\n
\n
\n

One of the biggest challenges in the development of customized software lies in a task that sounds rather simple: estimating the effort involved. The term implies an “estimate”, which basically shows the empirical nature of this task. Nevertheless, the most “accurate estimates” possible are required, particularly in the initiation phase, and in some cases these are even used as the basis for contracts.<\/em><\/p>\n\n\n\n

In order to estimate the scope of a project for quotation and implementation in advance, person hours or person days are traditionally used. This entails a number of problems and risks. Complex tasks are often impossible to estimate before the project begins, and overly generous buffers or short timeframes often result in inaccurate quotations.<\/p>\n\n\n\n



<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n

Contents<\/strong><\/p>\n\n\n\n

    \n
  • Everything is relative<\/li>\n\n\n\n
  • Factoring in different speeds<\/li>\n\n\n\n
  • Win-win situation: advantages for customer and software developer<\/li>\n\n\n\n
  • Author<\/li>\n<\/ul>\n<\/div>
    \"Softwareproject\"<\/figure><\/div>\n<\/div>\n<\/div>\n\n
    \n
    \n
    \n
    \n

    Everything is relative<\/h3>\n\n\n\n

    Estimation with story points is different: it is not based on absolute values, but on relative ones. Story points can be applied to different values that define the complexity of a task. However, the most common is a general assessment of the scope or effort. A direct conversion into a concrete time statement is not possible for the time being.<\/p>\n\n\n\n

    Story points are used by members of the development team to estimate tasks in relation to each other. As an example, a known task is defined by a team, which provides a starting value for further estimates with the associated estimate (e.g. 3 story points). Each future task is now estimated by the entire development team in relation to this metric. It is usually very easy for people to estimate an effort as “greater than” or “less than”, which is why story points have a first advantage at this point. Furthermore, story points are used in an adapted Fibonacci sequence, which includes the values 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and \u221e. This scale allows an estimation in increasing ranges, which makes it possible to recognize tasks that are not yet precisely specified or too large. It is not necessary to use this scale in its entirety. Such an estimation is carried out by the development team, e.g. with cards in “Planning Poker”.<\/p>\n<\/div>\n\n\n\n

    \n
    \"Story<\/figure>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n
    \n
    \n
    \n
    \n

    Factoring in different speeds<\/h3>\n\n\n\n

    In order to be able to use story points for agile software development, another value is required: the team velocity. The team velocity indicates how many story points the team can achieve on average per iteration. This value is variable and usually changes over the duration of a project, which is why continuous observations and adjustments are necessary. Above all, the stability of the team composition is an essential prerequisite for this. The reason for this is that the estimation is not only relative to the tasks, but also independent of the performance potential of the individual team members. A task with 3 story points can mean an actual time expenditure of 5 hours for one team member and only 3 hours for another team member. Since story points are assigned as a team and the tasks are also processed as a team with a known team speed, the possible scope of implementation of an iteration is easy to predict.<\/p>\n\n\n\n

    If three values are used for the team speed, namely the average, the fastest and the slowest of the last 6 iterations, a corridor can be specified for the predictability of the implementation duration, which offers further advantages in terms of planning. This makes it easy to identify tasks in a backlog which are not possible in terms of time according to the current planning or which can be guaranteed.<\/p>\n<\/div>\n\n\n\n

    \n
    \"Entwicklung\"<\/figure>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n
    \n
    \n
    \n
    \n

    Win-win situation: advantages for customer and software developer<\/h3>\n\n\n\n

    Estimating with story points therefore offers customers the best possible transparency for planning, monitoring and adapting a project roadmap. This means that reliable statements can be made about feasibility, completion, etc. despite the agile approach. The development team is also guaranteed predictability and agility at the same time. RISC Software GmbH has been successfully using Story Points in agile projects for some time now.<\/p>\n<\/div>\n\n\n\n

    <\/div>\n<\/div>\n<\/div>\n<\/div>\n\n
    \n
    \n
    \n
    \n

    Contact<\/h3>\n\n\n\n
    \n
    \n

    <\/p>

      <\/ul><\/div>\n
      \n
      \n<\/fieldset>\n
      \n\t
      \n\t\t

      \n\t\t

      \n\t
      \n\t\t

      \n\t\t

      \n\t
      \n\t\t