It’s very crucial to do Agile Estimation at different Levels and proper planning is required, management and estimating the total effort that we are going to implementing, testing, delivering the desired product to the Customer in terms of time specified deadline within it. With huge estimations in an agile project, there may be no proper planning, management, which leads to an end in delivering the undesired products and leaving the customer unsatisfied. A Good estimation helps product owners to optimize efficiency and impact.
Many of the agile teams, we know some of the organizations are using planning poker for their agile estimation. Agile estimations with planning poker are sometimes won’t work. Reason for this can is estimation features are too large, the team is not inspired to poker for 300 stories, there are not enough detailed pieces of information available on the item to be estimated or there is not enough time to do an accurate estimation on a full backlog. The main principles used behind agile estimation are using a relative estimation, allows the discussion derive more information about the items, create a mutual understanding and respect about the solutions, create a team to the committee on the work agreed upon, strengthen teams relationship for collaborating. All estimations are done in relative units….. Usually story points.
Here are 7 agile estimation techniques used in Planning Poker.
- Planning Poker
- T-Shirt Sizes
- Not Voting
- The Bucket System
- Large/Uncertain/Small
- Affinity Mapping
- Ordering method
Here is a great video about How to Estimate Story Points in Agile:
Planning Poker:
All the participants use numbered playing cards and estimating the items. Voting is done anonymous, a discussion is made when there are large differences. Voting is repeated until the whole teams reached consensus about the accurate estimations. Planning poker works well when you have to estimate a relatively small number of items (max 10) in a small team (5-8 people).Tips:- Try to keep voting between affordable numbers. Maximize the highest card to 13 points.
T-Shirt Sizes:
This is a good technique for estimating a large number of backlog relative large items. Especially sometimes we have several concurrent scrum teams working on the same products. Items are estimated to t-shirt sizes: XS, S, M, L, and XL. The decisions about the size are based on open and mutual collaborative discussions. This method is an informal and quick way to get a rough feeling about the total size of your backlog.
Dot Voting:
When we were faced with a relatively small set of items and in need of super and simple effective techniques to estimate you can use Dot Voting. This method originated form decision making, you can use it for estimating. Each person gets a small number of small stickers and can choose to vote for the individual items. if more dots is an indicator of a bigger size. Works well in both small & large group. You have to limit the number of estimated items.
The Bucket System:
It’s much faster than planning poker is the Bucket System. This system is a super alternative when estimating a huge number of items with a large group of participants. Create several buckets in the sequences of planning poker, groups estimate the items by placing them in these “buckets”. Buckets usually different sheets of brown paper where you can place the sticky notes with the items. But you can also use actual baskets to limit discussions about an already processed item.
Large/Uncertain/Small:
A super-fast method of rough estimating in the Large/Uncertain/Small methods. The team is being asked to place the item in one of these categories. The step is to categorize the obvious items to two extreme categories. Next, the groups can discuss more complex items. This is actually a simplification of the bucket system. The system is especially good to use in smaller groups with comparable items. Next, you can assign sizes to these 3 categories.
Affinity Mapping:
Methods based on finding similarities in the estimated items, the team is asked to group them together. The best way of executing this is a visual way and orders them to form small groups to large. It works best with a small group of people and a relatively small number of items. You can assign estimation numbers to the different groups.
Ordering method:
This is an exercise where you get an accurate image on the relative size of items. This works best in a small group of expert. All items are placed in random order on a scale label ranging from low to high. Every participant is being asked to move one item on the scale. Each move is just one spot lower or one spot higher or passes the turn. This continues till no team member want to move items and passes their turn. The ordering protocol is a method of getting fine-grained size estimates. Works best with a relatively small group of people and a large number of items.
User Story estimation:
The story point represents a relative sizing of the user stories. It’s a unit of estimation used by the agile team to estimate User Stories. When a product owner wants features to be implemented he/she desires to know how fast the team can complete the features and how many resources it will take to complete the works. From the developer perspective view, it’s next to impossible predicted the exact times in which he/she can complete the works. The person can however give a rough estimation in terms of how much time it might take to complete the work. Note that instead of “will” the developer chose to use “might” because is not absolutely “sure” about the time factor but “feels” it might take that much time. This is user story estimation in a nutshell.
Consider following factors while estimating stories:-
- Complexity: Consider and understand the complexity of the story.
- Risk: Consider the team’s inexperience with developing this story.
- Implementation: Consider the implementation factors and issues.
- Deployment: Consider the deployment requirements in projects.
- Interdependencies: Consider other outside issues and clear notes of the workflow.
Advantages of using story points for estimating work:
- Story points are a measured in relative size and complexity.
- Points are unit less, meaning as a scale, only valuable to compare against each other within the same team and time intervals.
- Estimating in story points allows/encourages everyone, including business people to participate in the estimation process (using Planning Poker).
- Estimating in story points is fast and easy.
- Story points initiate high-level discussions about everything that is involved in a project.
Steps for estimate stories:-
- Identify base stories.
- Talk through the detailed requirements.
- Discuss and note down points.
- Raise questions if any:-
- Requirement
- Technical Feasibility
- Acceptance Criteria
- Dependency
- Expertise
- Agree upon estimated size.
Agile Metrics:-
However, choosing a great metrics isn’t always easy right. When simultaneously using managing multiple agile projects and incorporating new agile initiatives, it can become difficult to measure the impact your changes are making, or if your team is actually improving. So what’s a company to do? Gaining an accurate work of what is actually happening; its imperative businesses use a combination of both business and agile metrics to keep track of projects. Business metrics helps to measure the success of your agile initiative, and agile metrics will allow you to continuously improve upon processes and deliver exceptional results to clients—which should be the entire mission of an agile approach. Metrics and measurements are standard practice in waterfall projects, due to long project time’s extensive costs, and high-risk outcomes. project limit risk and the use of traditional waterfall metrics no longer happened, a better practice of the psychological and behavioral of motivating people, we can eliminate the use of old agile measures. This presentation combines theoretical background with real-life examples which are successfully applied agile metrics. Managers and executives a clear charter to use metrics effectively and things they may be focused on causing more harm than good.
Powerful Agile Metrics-
- Sprint Burn down chats
- Agile Velocity
- Lead Time
- Cycle Time
- Code Coverage
- Static Code Analysis
- Release Net Promoter Score
- Cumulative Flow
- Failed Deployments
- Escaped Defects
This all agile metrics are used for a successful project without any issues to be identified in the future, metrics will give you the result how the team will finish the project within time.
Conclusion
Our selection includes agile software development metrics, which will aid in delivering quality software on time while ensuring the well-being of your team members. Using each and every member of the metrics on the list is not a precondition for creating shippable software products. In the end, the choice depends on a team’s scrum or Kanban master, the team, and the agile culture in the organization or the team.
For more blogs: https://blog.aleph-technologies.com/
Aleph Technologies is a premier IT training and staffing group with state of the art facilities based in Dallas, Texas. Aleph Technologies specializes in providing hands-on classroom based and onsite IT certification training courses taught by expert instructors with practical industry experience.
