10 Eylül 2017 6971 0 AGILE DEVELOPMENT Hakan Aksungar
In this BLOG article I will talk about Forecasting Techniques used in Agile Development Approaches. But let's start with estimating how to do traditional methods before you come;
Traditional Estimation
The project begins with the signing of the contract by the approval of the sponsor or customer by the time-cost-scope and quality plans of the ideas for the product or service constituting the project scope. It is estimated how long it will take to collect the requirements and deliver the products or services that meet those requirements. After the functional features are extracted, the development team makes technical design and architectural plan development estimates. When the planning studies are completed, estimation based on the basic plan is made. The team also estimates capacities by resource type and is projected with capacity and known dependencies on the project plan. At this point, a timetable is created and shared with the stakeholders, where the project team feels safe.
In traditional approaches, this estimation process may take several weeks to several months to complete depending on the size of the project.
If a project includes a timeout, the Project team can see that there is not enough time to deliver all the features that the functional features, designs, and estimates make. The team may then have to compromise quality and the like that meet the timeline for the project, recognizing that the features that are not to be tracked have spent valuable time in anticipation.
Agile Estimation Techniques
Agile forecasting techniques overcome the shortcomings of estimation in traditional development methods.
You will not be able to design and predict all functions without ensuring that the sorting order comes up and features are required. As the project progresses, you agree that you can be more precise and learn more about features, using the incremental predictive approach to predict the outcome. Agile estimates,
- Simple
- Relative size.
Agile Estimates are not normally assessed as anthropomorphic; Abstract-relative measures are used.
Estimates are based on estimates of relative size rather than estimating the exact size (hour, man day, etc.) of a job.
Relative Sizing and Story Point Estimating echniques
.jpg)
Relative estimation is to estimate tasks or user stories separately and not by absolute unit of time, but by grouping tasks by comparison or equivalent difficulty ratings.
Traditional software teams offer estimates in a certain time format, such as day format, week, month, but Fibonacci numeric sequences such as Agile Teams, Story Point, 0, ½, 1, 2, 3, 5, 8, 13, 20, Measures the relative effort of the work: It may seem intuitive, but this abstraction is actually useful because it forces the Team to decide around the difficulty of working. Here are a few reasons to use Story Point scores:
Estimates do not include accounts that are not relevant to the current project.
History removes emotional attachment from the middle.
By guessing that each team will work on a slightly different scale, it means that their speed (measured points) will be naturally different.
The team, Product Backlog, takes a task, briefly discussed, and each member mentally generates an estimate. Then everyone holds a card with a number that reflects their guesses. Everyone agrees perfectly, if not, some time is spent to understand the logic behind different estimates (not much time, just a few minutes). No task will work more than 16 hours. You can say that the upper limit of Story Point is 20 points. When your team has something above the 16-hour (or 20-point) spike, it indicates that you need to break up the more detailed pieces.
Accumulation is a rough estimate for deeper tasks. As team members really start working on these tasks, the requirements may change and your application will definitely change. Therefore, previous estimates will not be accurate. Estimating a job that is likely to slip is not time consuming.
Planning Poker® Estimating Technique
For many companies that use Agile Development Approaches, Planning Poker Technique is used for estimation.
I teach Planning Poker in my training.
Planning Pokeri is an estimation technique that uses the idea of user consensus to estimate the effort required to create relative dimensions of the stories.
Each team member has a deck of cards in his hand. Each card is numbered with Fibonacci numbers (?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, 500, etc.).
Represents the complexity of the user story in terms of time and effort, as predicted by team members. Team members help each user to make an assessment to ensure that they are better understood before giving up their story at the development stage.
Follow us to learn more about Agile Development and Agile Transformation approaches!
