# Qualified

• Scope Concept

• Estimates, Targets, and Commitments

• Overestimate vs Underestimate

• Decomposition and Recomposition

• Analogy-based estimations

• Story based estimations

---

# Scope Concept

Scope involves getting information required to start a project, and the features the product would have that would meet its stakeholders requirements.

The term scope has two distinct uses:

• Project Scope: the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions
• Product Scope: the features and functions that characterize a product, service, or result

If requirements aren't completely defined and described and if there is no effective change control in a project, scope or requirement creep may ensue.

Scope Management is the listing of the items to be produced or tasks to be done to the required quantity, quality and variety, in the time and with the resources available and agreed upon, and the modification of those variable constraints by dynamic flexible juggling in the event of changed circumstance called as Scope creep.

---

# Estimates, Targets, and Commitments

---

Examples

• "We need to have this release stabilized in time for the holiday sales cycle."
• "These functions need to be completed by July 1 so that we'll be in compliance with government regulations."
• "We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."

Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.

---

---

# Overestimate vs Underestimate

Overestimate

If you give a developer 5 days to deliver a task that could be completed in 4 days, the developer will find something to do with the extra day. If you give a project team 6 months to complete a project that could be completed in 4 months, the project team will find a way to use up the extra 2 months. As a result, some managers consciously squeeze the estimates to try to avoid Parkinson's Law.

Another concern is Goldratt's "Student Syndrome" (Goldratt 1997). If developers are given too much time, they'll procrastinate until late in the project, at which point they'll rush to complete their work, and they probably won't finish the project on time.

Underestimation

• Reduced effectiveness of project plans Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that's smaller than it should be. They can undermine the ability to coordinate among groups—if the groups aren't ready when they said they would be, other groups won't be able to integrate with their work.

• Statistically reduced chance of on-time completion Developers typically estimate 20% to 30% lower than their actual effort (van Genuchten 1991). Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.

• Poor technical foundation leads to worse-than-nominal results A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don't put enough focus on requirements and design, you'll get to redo your requirements and redo your design later in the project—at greater cost than if you'd done those activities well in the first place (Boehm and Turner 2004, McConnell 2004a). This ultimately makes your project take longer than it would have taken with an accurate estimate.

• Destructive late-project dynamics make the project worse than nominal Once a project gets into "late" status, project teams engage in numerous activities that they don't need to engage in during an "on-time" project. Here are some examples:

  • More status meetings with upper management to discuss how to get the project back on track.
  • Frequent reestimation, late in the project, to determine just when the project will be completed.
  • Apologizing to key customers for missing delivery dates (including attending meetings with those customers).

---

# Decomposition and Recomposition

Decomposition is the practice of separating an estimate into multiple pieces, estimating each piece individually, and then recombining the individual estimates into an aggregate estimate. This estimation approach is also known as "bottom up," "micro estimation," "module build up," "by engineering procedure," and by many other names (Tockey 2005). Decomposition is a cornerstone estimation practice—as long as you watch out for a few pitfalls.

# The Law of Large Numbers

The team's estimate benefited from a statistical property called the Law of Large Numbers. The gist of this law is that if you create one big estimate, the estimate's error tendency will be completely on the high side or completely on the low side. But if you create several smaller estimates, some of the estimation errors will be on the high side, and some will be on the low side. The errors will tend to cancel each other out to some degree. Your team underestimated in some cases, but it also overestimated in some cases, so the error in the aggregate estimate is only 7%. In your estimate, all 24% of the error was on the same side.

Recomposition

Feature	Best Case (25% Likely)	Most Likely Case	Worst Case (75% Likely)	Expected Case (50% Likely)

---

# Analogy-based estimations

Estimation by analogy, which is the simple idea that you can create accurate estimates for a new project by comparing the new project to a similar past project.

Here is a basic estimation by analogy process that will produce better results:

• Get detailed size, effort, and cost results for a similar previous project. If possible, get the information decomposed by feature area, by work breakdown structure (WBS) category, or by some other decomposition scheme.
• Compare the size of the new project piece-by-piece to the old project.
• Build up the estimate for the new project's size as a percentage of the old project's size.
• Create an effort estimate based on the size of the new project compared to the size of the previous project.
• Check for consistent assumptions across the old and new projects.

---

# Story based estimations

The story is the unit of functionality in an XP project. We demonstate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer, and small enough so that the programmers can build half a dozen in an iteration.

A user story is a chunk of functionality (some people use the word feature) that is of value to the customer. It provides a simple way for developers and customers to chop up what the system needs to do so the system can be delivered in pieces.

• Stories must be understandable to the customer.
• The best user story is a sentence or two that describes something important to the customer
• The story represents a concept and is not a detailed specification.
• Stories need to be of a size that you can build a few of them in each iteration
• Stories should be independent of each other.
• each story must be testable

Base your story estimates on a similar story you've already done. This story will take about the same amount of time as a comparable story.

There are three keys to effective estimation:

• Keep it simple
• Use what happened in the past
• Learn from experience

We should respect: Business Value & Technical Risk

---

# Note

• WBS

  WBS (work breakdown structure) - декомпозация проэкта на меньшие части

• Planning Pocker

  • используются карты с цифрами Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89) для оценки user stories + '?' + 'чашка кофе'
  • минимальная и максимальная оценки поясняются

• Bucket system

  • на доске рисуются ведра с числами Фибоначчи
  • команда обсуждает вместе 3-5 историй, раскладывая их в ведра
  • дальше все берут самостоятельно оценивать п несколько Story