Changes for page Planning Game

Summary

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

Details

Page properties

Content

...	...	@@ -1,9 +1,9 @@
1	1	# User Stories
2	2
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:
	3	+In Agile, **the project workload is broken down into user stories** and estimated, prioritized, and assigned. 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		-* 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		-* Short form: A minimal set of words that hint at the underlying interactions, such as "Login".
	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	+* Short form = A minimal set of words that hint at the underlying interactions, such as "Login".
7	7
8	8	# Iterations
9	9
...	...	@@ -36,10 +36,10 @@
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.
37	37	* Stakeholders select cards from the top of the story deck so that the sum of the points of all the selected cards matches the expected velocity. The stories on these selected cards will be implemented in the iteration. Remember that some stories may depend on other stories that need to be implemented first.
38	38	* **Story Deck Evolution**
39		- * Solved stories are removed from the Story Deck. As the project progresses, new usage requirements may emerge and be added as new cards to the Story Deck. Stories could also split or merge.
40		- * Estimated effort and business value are affected by the evolution of the project. Therefore, stories need to be re-evaluated and the story deck re-ordered on a regular basis, i.e. in the IPMs.
41		- * There may be stories that do not currently have a favorable ROI and are not worth implementing. They remain in the story deck because there is a chance that their estimated effort and business value will change over time, making them worth implementing later. Conversely, some stories may become irrelevant over time.
42		- * If the story deck has no stories with a ROI that makes them worth implementing, the project ends.
	39	+ * **Stories Evolve**: Solved stories are removed from the Story Deck. As the project progresses, new usage requirements may emerge and be added as new cards to the Story Deck. Stories could also split or merge.
	40	+ * **Estimates Evolve**: Estimated effort and business value are affected by the evolution of the project. Therefore, stories need to be re-evaluated and the story deck re-ordered on a regular basis, i.e. in the IPMs.
	41	+ * **Keep All Stories in the Deck**: There may be stories that do not currently have a favorable ROI and are not worth implementing. They remain in the story deck because there is a chance that their estimated effort and business value will change over time, making them worth implementing later. Conversely, some stories may become irrelevant over time as their estimated ROI decreases.
	42	+ * **Project End**: If the story deck has no stories with a ROI that makes them worth implementing, the project ends.
43	43
44	44	### During Iteration
45	45
...	...	@@ -57,4 +57,8 @@
57	57	* **Passing Tests**: Show that all unit and acceptance tests have passed, including those from previous iterations.
58	58	* **Demo Server**: Ideally, stakeholders should be able to interact with the latest release of the system on their own, for example on a demo server separate from the production server. This also prevents developers from being tempted to hide things that do not work.
59	59	* **Progress Update**: At the end of an iteration, sum the points of each <ins>completely</ins> finished story and add that value as a data point to the [[agile charts|doc:.Agile and Data.WebHome]]. Unfinished stories and all their points are ignored and moved to the next iteration.
60		-* **Iterations do not fail**: Initial velocity estimates are often overly optimistic and therefore higher than the actual measured velocity. The goal is a realistic view of team productivity. Iterations don't fail; they adjust the velocity prediction.
	60	+* **Iterations do not fail**: Initial velocity estimates are often overly optimistic and therefore higher than the actual measured velocity. The goal is to provide a realistic view of team productivity, not an accurate prediction. Iterations don't fail; they adjust the velocity prediction.
	61	+
	62	+## Story-Driven Development
	63	+
	64	+In projects, there may be many interdependent stories to implement, so the final design will be very complex and impossible to predict in advance. Therefore, the initial [[waterfall|doc:Software Engineering.Agile.Problems of Waterfall.WebHome]] planning is likely to fail. The solution is to implement the stories sequentially, even if it means redesigning the previous design frequently. This breaks the one big complex problem into many small but manageable chunks. Even when working more informally or alone, it makes sense to have a story deck. It reduces the mental load of having to design everything in advance, and allows you to focus on the current simple story that needs to be implemented.