Visual Studio Application Lifecycle Management 2010 脑图学习系列 之二 Creating a Great Product Backlog
Posted on 2010-04-29 09:34 Patrick Zhang 阅读(1911) 评论(1) 编辑 收藏 举报Visual Studio Application Lifecycle Management 2010 脑图学习系列 之一 Scrum framework MSF for Agile v5.0
如何写好use story 如何写好task 开始很困扰我， 学习后有了一些理解，总结了一下，与大家分享：
脑图上传到这里，可以下载. 欢迎指正
http://www.xmind.net/share/_embed/nus_intel/great-product-backlog/
Outline:
Great Product Backlog
1 suggests the form “As a <User>, I need to <Action> in order to <reason>”.
When your team creates a user story, make sure that it represents customer value by answering the following questions:
-
Who the user is
-
What the user needs to do
-
Why the user needs to do that
2 Characteristics
2.1 Small enough to be implemented in the sprint
2.2 Just detailed enough to describe and estimate the work that is required to implement the story
2.3 Acceptance criteria defined
3 INVEST in Stories
3.1 I - Independent
3.1.1 not overlap in concept
3.1.2 can schedule and implement them in any order
3.2 N - Negotiable
3.2.1 not an explicit contract for features
3.2.2 co-created by the customer and programmer
3.2.3 captures the essence, not the details
3.3 V - Valuable
3.3.1 valuable to the customer
3.3.2 when splitting stories. Think of a whole story as a multi-layer cake
3.3.3 Making each slice valuable to the customer
3.4 E - Estimable
3.4.1 just enough to help the customer rank and schedule the story's implementation
3.4.2 is partly a function of being negotiated
3.4.3 also a function of size
bigger stories are harder to estimate
3.4.4 function of the team
vary depending on the team's experience
3.5 S - Small
3.5.1 typically represent at most a few person-weeks(days) worth of work
3.5.2 Smaller stories tend to get more accurate estimates
3.6 T - Testable
If a customer doesn't know how to test something, this may indicate that the story isn't clear enough, or that it doesn't reflect something valuable to them, or that the customer just needs help in testing
3.6.1 I understand what I want well enough that I could write a test for it
3.6.2 writing the tests early helps us know whether this goal is met
4 SMART Tasks
4.1 S - Specific
4.1.1 enough that everyone can understand what's involved in it
4.1.2 keep other tasks from overlapping
4.1.3 understand whether the tasks add up to the full story
4.2 M - Measurable
4.2.1 can we mark it as done?
4.3 A - Achievable
4.3.1 should expect to be able to achieve a task
4.4 R - Relevant
4.4.1 every task can be explained and justified
4.5 T - Time-boxed
4.5.1 limited to a specific duration
5 Epics and Themes
5.1 Epics are very large user stories that represent a significant amount of work
5.2 Break an epic down, may create many themes and other, smaller user stories.
5.3 Themes are user stories that are fairly large, generally larger than you would implement in a sprint
5.4 Before your team implements a theme, it must be broken down into smaller user stories.
6 Spikes
Your team will sometimes need to do work that is not a direct implementation of a user story. This work is called a spike.To create a spike in Team Foundation, create a user story work item, set the type to Spike, and then prioritize it in the product backlog together with the other user stories
6.1 Research
there are open questions about a user story that must be answered before the user story can be fully broken down into tasks and estimated.The team determines how many hours it is willing to dedicate to that research and writes that number as the timebox for the spike. None of the stories that are written during the spike can be done during that iteration. The work must be scheduled for a future iteration by using the product backlog.
6.2 Bug Debt
If you cannot fix it on the same day that you found it, you should create a bug work item to make sure that you do not lose track of it.If your team does accumulate bugs, create a user story, and link the bugs to the spike so that it can be estimated and prioritized together with other user stories and spikes
6.3 Process or Engineering Improvements
These improvements are often identified during the sprint retrospective and daily scrum meetings
Visual Studio Application Lifecycle Management 2010 脑图学习系列 之一 Scrum framework MSF for Agile v5.0
