Extreme programming practices: Difference between revisions

Content deleted Content added
No edit summary
Tag: section blanking
Undid revision 720432139 by 122.15.171.149 (talk)
Line 33:
==== Release planning ====
 
===== Exploration phase =====
 
This is an iterative process of gathering requirements and estimating the work impact of each of those requirements.
 
*Write a Story: Business has come with a problem; during a meeting, development will try to define this problem and get requirements. Based on the business problem, a story ([[user story]]) has to be written. This is done by business, where they point out what they want a part of the system to do. It is important that development has no influence on this story. The story is written on a user story card.
*Estimate a Story: Development estimates how long it will take to implement the work implied by the story card. Development can also create spike solutions to analyze or solve the problem. These solutions are used for estimation and discarded once everyone gets clear visualization of the problem. Again, this may not influence the business requirements.
*Split a Story: Every design critical complexity has to be addressed before starting the iteration planning. If development isn't able to estimate the story, it needs to be split up and written again.
 
When business cannot come up with any more requirements, one proceeds to the commitment phase.
 
===== Commitment phase =====
 
This phase involves the determination of costs, benefits, and schedule impact. It has four components:
 
*Sort by Value: Business sorts the user stories by [[Business Value]].
*Sort by Risk: Development sorts the stories by risk.
*Set Velocity: Development determines at what speed they can perform the project.
*Choose scope: The user stories that will be finished in the next release will be picked. Based on the user stories the release date is determined.
 
====== Sort by value ======
 
The business side sorts the user stories by business value. They will arrange them into three piles:
*Critical: stories without which the system cannot function or has no meaning.
*Significant [[Business Value]]: Non-critical user stories that have significant business value.
*Nice to have: User stories that do not have significant business value.
 
====== Sort by risk ======
 
The developers sort the user stories by risk. They also categorize into three piles: low, medium and high risk user stories. The following is an example of an approach to this:
 
*Determine Risk Index: Give each user story an index from 0 to 2 on each of the following factors:
**Completeness (do we know all of the story details?)
***Complete (0)
***Incomplete (1)
***Unknown (2)
**Volatility (is it likely to change?)
***low (0)
***medium (1)
***high (2)
**Complexity (how hard is it to build?)
***simple (0)
***standard (1)
***complex (2)
 
All indexes for a user story are added, assigning the user stories a risk index of low (0–1), medium (2–4), or high (5–6).
 
===== Steering phase =====