User Stories Applied

summary: - estimating stories in story points, which are relative estimates of the complexity, efforts or duration of a story; - better as ideal day for estimating rather than taking into different impacts factors in to consideration - estimating stories needs to be done by the team, and the estimates are owned by the tea, rather individuals - triangulate an estimate by comparing it to other estimates - whether or not a team programs in pairs has no impact on story point estimates. Paire programming affects the team's velocity, not their estimates

Velocity means, on the specific approach of estimating of the efforts of your team, in one iteration, how many story points can be resolved Story points for one feature is better to be consistent (using same way or indicator as estimation - could have triangulate methods (put different story points stories on the same board to see whether applicable or consistent from each other)Story point for a same effort level estimation could change with time changes, due to the tech development, more familiar with the concepts or coding etc.If story is not aggregated to the subsequent stories, the approach or standards of estimation could be changed to reflect the actual efforts.

- start with goal stories - slice the cake

a far better approach is to write the replacement stories such that each provides some level of end to end functionality

- write closed stories

a closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished sth

- put constraints om cards- size the story to the horizon focus on one and expand , then expand another (trawl stories required as below) - role modeling via brain storm an initial set of user roles, organize the initial set, consolidate roles, refine the roles.) - gather stories via techs as user interviews, questionnaires, observations, story-writing workshops

Summaries: 1. To identify stories, start by considering the goals of each user role in using the system 2. When splitting a story, try to come up with stories that cut through all layers of the applications; 3. Try to write stories that are of a size where the user feels justified in taking a coffee break after completing the story 4. Augment stories with other requirememts gathering or documenting techniques as necesar for the project's domain and environments 5. create constraint cards and either tape them to a shared wall or write tests to ensure the constraints are not violated 6. Write smaller stories for functionality the team will implement soon, and write broad, high-level stories for functionality further into the future 7. Keep the user interface out of the stories for as long as possible 8. When practical, include the user role when writing the story 9. Write stories in active voice. 10. Write stories for a single user 11. Have the customer rather the developer write the story 12. Keep user stories short, and dont forget their purpose as reminders to hold conversations 13. dont number story cards

concerns for #11 & 13#11: The customer indicates the customer user proxy like BA or actual customer? very seldom the real customer will help to write the story ? also, if they wrote, then the key concern is how to ensure the understanding between customer & BA is correct, so product owner can pass this correct to devs?#13: agree of not mention feature abstractly. the thing is that we can use number and make this still concrete for talking about; and this makes thinks easy to maintain or track on several places - like story & jira & action list etc,

标题是第一行笔记, 不要急着调样式啊孩纸!Estimating stories.The description of stories is a reminder for developers and business people to communicate. It is not the more details the better. The true meaning of a story can't be completely described by the text. Dev and customers usually have different opinions about one same sentence, and often customers don't know what they really need when they write this story. Dev needs to find out the real requirement during the discussion with customers.Estimating as a team, find out why some people give larger story points.Everything takes 4 hours.