More importantly, if we were shown two T-shirts of different sizes and asked to decide which one is bigger, we would almost certainly get it right. If we were given a big pile of T-shirts and asked to sort them into three piles by size, we would probably do pretty well with that task too. The T-shirt sizing Agile technique is part of the basis of Agile estimation because it's so relatable to something many of us deal with on a regular basis. In the same way we'd have a hard time guessing the exact width of a T-shirt, it can be difficult for development teams to guess exactly how long a task will take.
Instead, just like how we'd find it easier to rank T-shirts by their sizes, teams are better at ranking stories and work by relative size. Although many teams find project estimating with T-shirt sizes easy and intuitive, many teams ultimately choose to go with numerical project estimates that allow for quantitative calculations. Using story points, each estimated story is assigned a value such as 2, 3, or 5.
A value of 3 is meaningless by itself. Story point values are selected from an estimation scale. The increasing gaps in the Fibonacci scale are useful because as stories get larger, there are more uncertainties and estimation becomes more difficult. Generally, stories at the largest end of the spectrum are considered too large to reasonably estimate. These stories would be assigned 40 story points and be flagged to be broken down into smaller stories somewhere down the line.
Just as you might express your rate of progress in a car in terms of miles per hour, in Agile we express velocity in terms of story points per sprint iteration. Velocity is calculated by simply adding up the story points of all the stories completed by a team in a sprint.
Consider that a team completed a 3-point story, a 7-point story, and a point story during the prior 2-week sprint. Adding the three stories together gives a velocity of 20 points. Velocity becomes a useful measure when we make the assumption that, over time, teams tend to complete a similar amount of work in each sprint. We can use this information to plan better sprints with more realistic, accomplishable expectations. A benefit of using velocity and story points to build estimates is that the process separates estimation of effort from the estimation of duration.
This distinction makes it much easier to update estimates over time, and the process can even be seen as self-correcting. Consider that after the first sprint of a project you expected a velocity of 20, but after the next three sprints it turns out that the velocity is actually The refined velocity can be applied to the remaining backlog for a more accurate estimate of the number of sprints required without necessarily needing to revisit the original story point estimates.
With some basic Agile estimation concepts under our belts, we can turn our attention to how these concepts are put to use. There are a handful of tried-and-true techniques that Agile teams have developed over the years. The last point above, the need to be efficient in your estimation practices, is critical to the Agile mindset. Software estimation suffers from the phenomenon of diminishing returns. There are basic, simple Agile estimation techniques that can produce fairly good results.
Beyond those project estimation techniques, you can expend tremendous additional effort with little or no demonstrable improvement in the estimate. In Agile, we acknowledge this fundamental limitation and embrace simple estimating methodologies that give us the information we need to support effective planning.
Planning Poker is perhaps the most popular estimation technique, and most Agile teams use some variation of the approach. Planning Poker is an exercise that involves the entire development team. Traditionally, each member has a deck of cards that shows the numbers of the story point scale. As stories are reviewed, each team member silently arrives at a score and then all team members reveal their selected card at the same time.
The team then discusses the scoring, and members contribute their rationale for the score they awarded.
After discussion, the team again votes with their cards. The goal, and typical outcome, is to converge upon a single, agreed-upon score within a few rounds. Affinity Grouping is an alternate method to Planning Poker in which team members group items into tiers based on relative size.
The basic process is usually carried out with sticky notes on a board. The notes are arranged with smaller items going to the left and larger items to the right. In addition, combinations of sizing methods including hybrids can be used on larger agile projects to take advantage of each of their strengths and compensate for their weaknesses when there is a fit; i. There was no consensus over which method is best.
All of the methods including combinations have fans and detractors and were deemed useful. Each has been used effectively by survey participants. Each has strengths and weaknesses. Each can be used effectively when used singly or in combination with others appropriately by those who understand its fitness for use. However, managers seemed to prefer function points because sizing with them was repeatable because the method was rule-based and there are historical databases and benchmarks available.
Table 2 provides an overall assessment of the five primary sizing methods. We used the following nine criteria to perform the rating:. Selection of the best method is a function of the weighting assigned to each of these assessment criteria. For example, function points received the winning nod when evaluators gave preferences to repeatability, standardization, rule-based sizing methods.
On large projects, combinations of methods received the winning nods when those asked about them rendered their opinions. When asked about the accuracy of size estimates each method generates, Table 2 concludes that there is a lot of variability in results. As with traditional developments, the major cause of such variations seems to be requirements changes.
For agile development, stories are used to capture the requirements. Because agile views requirements elicitation as an exploration rather than a specification activity, they continuously change as development progresses and as users learn what they truly want the software to do. As a result, stories are added and deleted sprint by sprint. Agile projects maintain budget and schedule integrity by deferring and backlogging scope. This is done consciously by having the customer prioritize the features that get delivered each iteration or sprint.
Of course such tradeoffs assume that the architecture is stable and will not be broken as features are added and deleted sprint-by-sprint. It also assumes that the technical debt accrued can be sustained once the product is rolled out for sale or use. The usefulness of the size estimates was judged based on the breadth of its use. Analogies and proxies are used at the project level as well.
In contrast, function points are used enterprise-wide because they could be compared against industry past performance data and industry benchmarks. Finally, it just is too early to make a call for Halstead vocabulary because it is new and has not yet been widely used. From the data we collected we can conclude that estimating size maintains its importance for agile projects because of its relationship to resource estimation, measurement and risk assessment, i.
We can also confirm that there are many currently available resources, including sizing methods, models and relevant historical databases 29, 30, 31 , that can be used to effectively generate reliable software sizing estimates especially when they are adapted and tailored for use with agile methods.
There seems to be no end to the controversy over which sizing method is best and whether or not estimates are needed for software products being developed using agile methods.
Agile purists argue against estimates, while others argue for them. While the debate rages, agile projects continue to get bigger and more complicated. This trend is to be expected as more and more firms embrace agile methods as their preferred approach to develop and maintain software 32 including that generated on agile-at-scale projects. Because enterprises are also embracing agile methods in more areas than just software, new sizing measures are being introduced for other applications.
As an example, many system engineering organizations are transitioning to the use of agile methods. Like for software groups, their goal is to use measurement to improve both their estimates and their control over quality, timeliness, efficiency and effectiveness of the processes they use and the products they generate. Their main measure of size is the number of systems requirements. So far, there are no answers. The main question that needs to be answered in the near-term is whether existing or new sizing methods will take hold for use with agile methods.
Our assessment is that the five methods outlined in this article will continue to be employed especially as agile methods become used in wider contexts. Function points will dominate in enterprise-wide and larger projects. Analogies and proxies will be used as well especially in situations where past experience can be leveraged. Halstead sizing approaches may or may not take hold. It seems too early to tell as the approach is new and untried.
Combinations of methods will be exploited as agile methods are used more widely across disciplines and at the enterprise level. In other words, we see no surprises on the horizon in either the near- or long-term. Reifer as President of Reifer Consultants LLC, a software management consulting firm, is frequently called upon to help clients grow their business, startup large projects, solve operational problems, and introduce new technologies like agile methods, product lines and cloud computing.
He is in demand because he focuses on using metrics-based management approaches. Previously, while with TRW, Mr. While with the Aerospace Corporation, Mr. Reifer managed all of the software efforts related to the Space Shuttle.
Here's what you'll learn:. How to use strategic project fast tracking to save time and make the most of available resources. We started ITtoolkit. To learn more, visit us at Right Track Associates. If you'd like to learn how to quickly plan I.
Service Strategy Toolkit is the right course for you. Brought to you by the publishers of ITtoolkit. Start for free now! If you'd like to learn how to form and operate successful committees, destined to be more productive and less prone to conflict, the Project Committee Toolkit is the right training course for you.
If you'd like to learn how to how to streamline project management activities to get work done in less time, using the resources you have, then the Fast Track Toolkit online course is what you need. But the process should never be allowed to overtake the project. Project "Size" Defines Process "Scope" When it comes to projects and practices, one size may not fit all. Learn to Fast Track When it comes to managing, you need more than one approach to be consistently successful. Related Articles.
Here's the Key - Timing is Everything. About Us. Additional Articles. Practices Asset or Untapped Resource? That's O. Learn How to Make It!
0コメント