User Stories
- A story typically describes “what”. Here is a simple template: “As a [user role], I want to [goal] so that [benefit]“. The “so that [benefit]” clause is optional depending on how obvious the benefit is.
- Tools: XPlanner, Rally, Scrumworks Pro, Thoughtworks Mingle, and Card Meeting. The instructor said non of the tools handles hierarchical backlogs. See also Rally vs Scrumworks.
- Architectural considerations: If your project has a horizontal architectural. You may need to build the underlying infrastructure and plug-in new features. Practically, you may need to re-factor to add new modules. Another approach is to build features vertically. The risk of this model is that specific infrastructure build for a feature may need to be changed when adding a new feature. This vertical approach can enable a team to focus only on work that is needed to move forward faster in the near-term. XP demands vertical approach. The team should balance between these approaches depending on individual situation.
- How do you work with customers who only ask for bare minimum and often time ask for more later? For such customers unwilling to prioritize or accept the expectation, they may be asking the team to incur technical debt
- Building a common glossary is important at the beginning of the project to ensure everyone have a common understanding of terms that are in-use by the team. To handle overloaded terms, use qualification to provide a context.
User and User Roles
- Gaining access to users is important. Often times, only user proxies are possible.
- When defining user roles, a guiding question is “Does the team has to do any work to support that role?”
- As a brainstorm exercise, the whole team can do a “silent grouping exercise” to quickly generating ideas. Each member write their ideas on a sticky notes and post his/her notes on a wall. If there is a redundancy, just overlay the sticky notes. If one identified a misplacement, he/she can just relocate it. This exercise should be done silently.
- Translate “As a student, I should not do…” story into something similar to “As a student, I should …”.
- A non-human system can have a role. A programmer can be a user of feature of the system. For example, “As a programmer, I want an API for deleting widgets from the database.”
- Persona is an imaginary role that usually require research and typically a team only spend the time to write a few. This can be an effective way to target the team to build the system for specific type of users.
- A good story has the following properties: Idependent, Negotiable, Valuable, Estimatable, Sized appropriately, and Testable. Not all stories will have all these properties. A story should be at least valuable or the team should ask “why keep it?”.
- If stories has dependencies or may have variable cost due to the order of implementation, the team can annotate the story.
- A comment on independence: Extract technical commonalities among stories: Sometimes necessary to break down the work but not ideal because the the customer do not receive an independent feature by the completion of the the technical commonalities.
- Perhaps writing technical stories that product owners can understand. For example: Change from “All error handling and logging is done through a set of common classes” to “As a user, I awant all errors presented and logged in a consistent manner”
- A story that says “Refactor the payroll process code” because it will give the customer 10% performance gain. This story is not a very good one because it’s not testable at end of this story’s completion. An approach to this is to embed it into a related story and be transparent with the customers rather than have an independent story. In some cases, people might not even notify the customers. This approach may cause the following situation: The team might invest time and energy to do the refactor work without letting the product owner know. After the fact, the product owner might say that why did the team invest the time when that code base might be expected to retire in six months.
- If a story is too big and you don’t have to work on it, it’s okay. If you have to work on it and it takes weeks (i.e. longer than one iteration/sprint), you might want to break it down. Sometimes if multiple members need to work on the story, you might want to break it down. For example, the story may require legal review, you might create a new story for a separate team to handle the story.
- For some stories, a team might spend some time to acquire knowledge before estimate the work.
- Some people may attach a quality template with a story that define a test, scale of the test, minimally acceptable limit on the scale, a planned taqrget, best-ever/engineering limit, and current status. This will show the product owner that if the story is done or not.
Other guidelines on stories
- Closed Stories: A story that finishes with the achievement of a meaningful goal.
- Non-functional Requirements: performance, availability and other qualities. Testable characteristic is desired for stories on these topics. Identify system level non-functional requirements as early as possible and decide when to focus on these.
Estimation
- Every estimates comes with a probability. Estimate should be relative size. This enables velocity to calculate using the same unit and enable further statistical calculations.
- To ensure similar estimations, the team should define the size, scale, and 2 reference points.
- Story points or ideal days for the story estimation? Either one can work depending on a team’s preference. Task estimation usually done with ideal days. Ideal day estimation sometimes lead to unreasonable expectation. A story with 5 days estimation, does not automatically mean it will be done in 5 days. For story point estimation, some people may feel uncomfortable understand what it means.
- For stories that you don’t know, you may break it into two pieces: 1. uncertain part 2. learning/investigation part.
- A team should not do story point driven planning. i.e. pick the top x number of points for the next iteration. This is fast and dangerous way to plan. Initially, the team might be new to a particular technology may have a lower velocity than after working on it for six months.
- Estimates at task level may not match the associated story. Task estimation is at much higher precision than story estimation. Story estimation is used as a roiugh number for prioritizing the iteration/sprint.
- Estimate by Analogy: Avoid use a single standard. Instead, compare to multiple known stories.
- Some use the following scale: 1, 2, 3, 5, 8, 13. While some use the following: S, M, L, XL, XXL, X, infinity, pi (I am hungry and want to eat some pie). Everyone vote at the same time to avoid influence. If there are different votes, members can explain why they gave the vote. Next, people vote again. The goal is to reach consensus. See: planning poker
- Any time when the relative size change due to new information/understanding, re-estimate associated stories.
Sprint Planning
- For a 4 week Sprint, the Sprint planning may take half-a-day. Adding retrospective and sprint review meetings, the remaining development period maybe only 19 days. Sprint review meeting will be harder to schedule because it involves a lot of people not on the team. Therefore this meeting should be scheduled first. For wide time zone differences, some teams may choose to do sprint planning before sprint review and retrospective meetings.
- The goal of a sprint planning is commitment. The product owner runs sprint planning meeting.
- In part one of the planning meeting, product owner presents the stories, answer some questions, and leave. In part two of the planning meeting, the team break down the stories into taks. Product owner returns and everyone completes the planning meeting. The instructor recommend to have the product owner to be stand-by while the team break down the stories so product owner is available if the team encounters a question.
- A team should give consideration to capacity (i.e. how much time each member can allocate per-day – time spent on meetings – un-planned task – personal vacations). Watch out if one of the team members becomes is on critical path and does not run out of spare hours to work on stories.
- If a team completed all tasks, the team may start on the next story from the backlog. Make sure there are three times as many stories estimated in the backlog. The team may choose to address the technical debts or various pending issues. All these are typically done with negotiation.
