Changes for page Planning Game

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,6 +1,6 @@
1	1	# User Stories
2	2
3		-The goal of the planning game is to <ins>break down the projects work load into user stories</ins> and estimate, prioritize, and assign them. A user story, or often just called a 'story', is an abbreviated description of a feature of a system, told from the user's perspective. There are two forms:
	3	+**The goal of the planning game is to break down the projects work load into user stories** and estimate, prioritize, and assign them. A user story, or often just called a 'story', is an abbreviated description of a feature of a system, told from the user's perspective. There are two forms:
4	4
5	5	* Long form: A sentence that describes exactly how the user interacts with the system. "When I go to the login page, enter my credentials and click the login button, the home page appears."
6	6	* Short form: A minimal set of words that hint at the underlying interactions, such as "Login".
...	...	@@ -7,7 +7,7 @@
7	7
8	8	# Iterations
9	9
10		-Opposed to dividing the project schedule into distinct phases like in [[waterfall|doc:Software Engineering.Agile.Problems of Waterfall.WebHome]] workflow, in Agile <ins>the project schedule is broken down into iterations</ins> with a fixed size of usually two weeks. For example, a 1-year project could have 26 iterations of 2 weeks each. An iteration is not a mini-waterfall with specific phases that occur only once and in a particular order, such as planning -> design -> implementation -> testing. In an iteration, all phases are performed continuously, allowing for overlap and frequent revisits. For example, if a design problem arises during implementation, you simply redesign immediately and then continue implementing.
	10	+Opposed to dividing the project schedule into distinct phases like in [[waterfall|doc:Software Engineering.Agile.Problems of Waterfall.WebHome]] workflow, in Agile **the project schedule is broken down into iterations with a fixed size** of usually two weeks. For example, a 1-year project could have 26 iterations of 2 weeks each. An iteration is not a mini-waterfall with specific phases that occur only once and in a particular order, such as planning -> design -> implementation -> testing. In an iteration, all phases are performed continuously, allowing for overlap and frequent revisits. For example, if a design problem arises during implementation, you simply redesign immediately and then continue implementing.
11	11
12	12	## Goals of the Initial Iteration
13	13
...	...	@@ -20,7 +20,7 @@
20	20
21	21	### Start of Iteration
22	22
23		-* Each iteration begins with the **Iteration Planning Meeting (IPM)**. Meeting Setup:
	23	+* Each iteration begins with the **Iteration Planning Meeting (IPM)**.
24	24	* The purpose is to determine and prioritize stories to be implemented in the current iteration based on estimated effort and business value.
25	25	* The IPM allocates about 1/20 of the total iteration time. For a two-week iteration, this translates to a half-day IPM.
26	26	* The whole team and the stakeholders attend the meeting.
...	...	@@ -30,7 +30,7 @@
30	30	* Stakeholders rate stories based on their estimated business value. Some sample models for expressing business value are: important / unimportant (story), low / medium / high (business value), or even in points, similar to effort estimates. This value is also written on the story card.
31	31	* **Story Deck Ordering**: The order of the story deck is determined by the return on investment (ROI), simply the cost-benefit ratio between the estimated effort and the expected business value. The story with the best ROI should be at the top.
32	32	* **Implementation Plan**
33		- * The goal is to determine which stories should be implemented in the iteration.
	33	+ * The goal is to determine which stories should be implemented in the current iteration.
34	34	* Determine the expected [[velocity|doc:.Agile and Data.WebHome]] for the iteration:
35	35	* At the start of the first iteration, the team has no data on the team's actual velocity. Therefore, the team estimates which stories they think can be implemented in the first iteration.
36	36	* For subsequent iterations, the team expects the velocity of the current iteration to be the same as the velocity of the previous iteration, as this is the best guess.