NOTES: ALL OF THIS WAS NOT PROPERTIES OF MINE. JUST TAKING KEYPOINT HERE
Waterfall is a well-known software development model in which, the development process is carried out in a sequential pattern (Royce, 1987).
Issue: after the testing phase the requirement might need to be changed for fixing the problem that is existing in the system, because of this, the development process starts all over again. 100% schedule or cost overrun in the project.
During 2001 the Agile Alliance was formed, and the Agile Manifesto was published.
To measure the story points some sort of scales are used, these scales are relative in nature and the values can be numbers or any objects that are easy to compare (Ziauddin & Zia, 2012)
is the estimation process in which the related items are estimated based on 3 parameters of a user story - COMPLEXITY, UNCERTAINTY, and EFFORT.
According to the (Alliance, 2016), “Relative estimation is one of the several distinct flavors of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by grouping items of equivalent difficulty”.
refers to the estimation method in which user stories are measured based on the time like, estimation based on ideal hours (Alliance, 2016).
• Fewer data required • Adopt to special projects
• Its success depends on a team of experts
• Transparent technique • It provides clear results • Independent on programming language
• Much data required • The requirements must be clear. • Not adopted to changes in requirements. • Require historical data which are not available sometimes
• Adopt to changes in requirements • Reduced bias by involving a team of experts
• Its success depends on the expert • Estimation is relative to a team.
• The good quality of the data helps in constructing the machine learning-based effort estimation model used for validating the model’s accuracy.
• The ML model needs existing historical data.
• Change the structure during the learning process because of its adaptive nature.
• The main limitation of implementing this model is that there is no consensus on which model is the best.
• Easy to compare the sizes of the features/ functionality to each other to determine the relative size. • Require less time.
• With the pressure of the performance improvement, teams may increase story points, e.g. something that was 3 story points, now becomes 5 story points.
• It is better to have something that implies a range rather than an absolute number
• They are not additive; it is difficult to tell a boss you will be done in 3 mediums.
• Based on similar project experience • More accurate
• Information about past projects is required • Historical data may not be accurate
• It is based on use cases and can be measured very early in the project life cycle. • Easy to use and does not call for additional analysis.
• It can be used only when requirements are written in the form of use cases. • Technical and environmental factors have a high impact on UCP .
• Work best with teams at any experience also work with the team having less or no experience with story points already. • Work for the team that had never used planning poker before.
• If the estimating team is big, it may not fit in the board.
• It helps to prioritize the improvements during the sprint retrospective.
• It sometimes gives confusing or false results. • Participants can cheat by adding extra dots, peeling off dots or moving dots
• It can also be used with larger groups • Very large numbers of items can be estimated.
• Estimate roughly. • Relative results.
• Faster than planning poker. • Easier to play. • Simple setup • Team members having no experience of the method can be directly involved in estimation rounds.
• Once introduced, the method can be difficult to replace. • From a group size of more than nine people, a single round takes several minutes.
in software development does not mean to eliminate estimation, but exploring the distinct methods of solving the problems without asking the question “How long will it take?” (Heusser, 2013).
the requirement for estimation is decreased and the focus will be in measuring the development progress and predicting the future of the project
Estimation is the main concern for the software development industry, in particular, an accurate estimate always has become a matter of concern (R. Popli & Chauhan, 2014). Due to this, #NoEstimates has been creating a buzz in the software industry and it is an emerging movement within the agile community. So far, only one book “NoEstimates: How To Measure Project Progress Without Estimating” by Vasco Duarte (Duarte, 2015) and study (Hannay et al., 2018) is available.
estimation is a great area of concern but it is hard to calculate the accurate estimates of the unknown parts. In this situation, many teams are unable to deliver the committed work, because their estimates are often way off. They face project overruns and this restricts the companies from achieving their goal due to delayed delivery.
the team should immediately start working on those tasks so that, it will give feedback which helps in delivering the project.
The highest value or higher priorities (maybe risk) should be grouped, so that, the delivery helps on generating the feedback and throughput.
According to Boiten (2017), some of the notable features of #NoEstimates are:
It always takes longer than you expect, even when you take into account Hofstadter’s Law”
“Work expands to fill the time available for its completion”.
Essential complication or g(e) means the problem becoming hard within itself. For instance, the problem is hard, so the system is complicated.
Accidental complication or h(a) means not being good at our jobs or “we stuck at our jobs” due to various factors supposedly, the pressure from the organizational structure (till when will we be able to get approval for a new test environment?) and from how programs are written (development keeps on evolving so, things keeps on changing and functionality will be evolving).
concept started in 2005 and it is gaining popularity in recent years. According to (Leybourn & Hastie, 2018), “#NoProject is a movement and a philosophy that represents a set of principles, practices, and ideas that any organization can apply”. It can be seen as a modern agile approach that directs companies on continuous and market-validated value delivery. There are no hard and fast rules for the organization that adopts #NoProject, but if they want then they can evaluate it, experiment it, and then adopt #NoProject rules. (Leybourn & Hastie, 2018)
Common Activity:
• The expected outcomes should be defined in terms of metrics that truly provide values, instead of easy-to-measure vanity metrics. • Recognizing the first small step or experiment to validate the assumptions that are being made for obtaining the outcomes. • Execute that step. • Measure the results. • Examine the method and adapt to the reality of your learning. • Finally, continue the above steps, pivot, or stop if its already done enough (reached maximum value, or learned enough).
Both of them focus on delivery value. #NoEstimate removes the justification of estimates and helps the organization focus on value delivery first (Duarte, 2015). And, #NoProjects is the modern agile approach that directs companies on continuous and market-validated value delivery (Leybourn & Hastie, 2018).
most of the previous studies are focused on outlining the various estimation techniques available. The majority of studies also identified expert judgment to be the most popular estimation technique.
Demographics
Software Development Project
Quick and timely delivery Provide a sense of teamwork Increase adaptability of the team for accepting new feature Remove conflict among development and management teams as they agree on specific estimation. Easier forecast Cross-Functional team
Complexity and Uncertainty - Missing and changing requirements - Overlooking non-functional requirements Poor user stories -
Poor change control Scope creep - Scrum Master not guiding the team Unstructured group estimation process
Distributed teams - Dominant Personalities Inexperience - Knowledge sharing problem in team - Pressure of timeline - Unskilled team members -
Considering best case scenario - Purposely underestimating to obtain work -
Hardware - Ignoring testing effort - Insufficient customer involvement during estimation process - Lack of formal estimation process -
Tags: [