In short, it meets the just-enough-detail criteria.
Intime software code#
And the programmers will have time to code it and the testers to test it. The analyst will have time to figure out exactly what the text should say the user experience designer (UED) will have time to mock up two or three screens, show them to some users, get feedback, and create the best possible “help about” screen.
That first story can go from that short description to implemented code quite easily within a sprint. As a user I can enter a check in my register so that I can track who I pay.As a user I can see the current version, company website, and copyright in a "help about" dialog so that I know useful information about the product.We create an initial product backlog that includes these two user stories: To see why just-in-time and just-enough are appropriate targets, suppose we decide to write a checkbook program to compete with Intuit's Quicken product. My view is that each product backlog item (usually reflected as a user story by teams I train or coach) should be captured just in time and in just-enough detail for the team to go from product backlog item to working, tested feature within a sprint. While it’s true that this may be sufficient in many cases, it would clearly not be adequate in all situations. Many say that as little as possible should be done: the team should do no more than write a few words of a user story on an index card to represent each product backlog item. Having dispensed with the possibility that no work should be done in advance we are left to consider the question of how much work should be done in advance. The start date of the second sprint is knocked forward by the end of the first-like one billiard ball knocking into another. This approach leads to what I call “billiard ball sprints.” Without any planning, the team starts a new sprint on the day after the prior one ends, but spends the first two to five days “getting ready” to start the sprint. To see why, let’s take that view to its extreme: If we did nothing in advance to understand what we're building, we’d show up at the planning meeting and say, “Hey, what should we build this sprint? We were working on an eCommerce site yesterday, but I think maybe we should switch to writing a word processor.” The team would literally have nothing written down-no user stories and no product backlog. Should you write part of your product backlog and user stories before your first sprint? Some people want to take the stance that no work should be done in advance of the sprint.
0 kommentar(er)
