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
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
3.1.1 not overlap in concept
3.1.2 can schedule and implement them in any order
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.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.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.1 typically represent at most a few person-weeks(days) worth of work
3.5.2 Smaller stories tend to get more accurate estimates
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.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.1 can we mark it as done?
4.3.1 should expect to be able to achieve a task
4.4.1 every task can be explained and justified
4.5.1 limited to a specific duration
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
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.
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
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