This is part 1 of 4 of a post on how to iterate with RUP. The introduction to this post can be found at ScrumUP Fairytale - Part 4.
The term “Ready to Poker” means that the team is ready to estimate a story from the Product Backlog in such detail that they can accurately forecast if its implementation will fit in the upcoming Sprint. Stories to be prepared by the team so they can be pokered are the ones at the top of the Product Backlog (and sometimes explicitly planned in the Sprint Backlog). The best way to get a story Ready to Poker is for the team to be actively involved in preparing this story for implementation. Team members playing the role of Analyst, Developer and Tester work together with Subject Matter Experts, who represent the business. Starting point for these activities is the short description of a Use Case from the Use Case Model, describing what the user wants to do with the system and why. The activities involve detailing requirements so the team knows what the user wants, preparing test cases so the team knows how the solution will be accepted and do some designing so the team knows how to get to a solution. In Figure 35 through Figure 38 we build up a workflow explaining a RUP based process you can follow to get Ready to Poker. A key to the symbols used in this workflow can be found in here.
The term “Ready to Poker” means that the team is ready to estimate a story from the Product Backlog in such detail that they can accurately forecast if its implementation will fit in the upcoming Sprint. Stories to be prepared by the team so they can be pokered are the ones at the top of the Product Backlog (and sometimes explicitly planned in the Sprint Backlog). The best way to get a story Ready to Poker is for the team to be actively involved in preparing this story for implementation. Team members playing the role of Analyst, Developer and Tester work together with Subject Matter Experts, who represent the business. Starting point for these activities is the short description of a Use Case from the Use Case Model, describing what the user wants to do with the system and why. The activities involve detailing requirements so the team knows what the user wants, preparing test cases so the team knows how the solution will be accepted and do some designing so the team knows how to get to a solution. In Figure 35 through Figure 38 we build up a workflow explaining a RUP based process you can follow to get Ready to Poker. A key to the symbols used in this workflow can be found in here.
The Analyst has several sessions or workshops with the relevant Subject Matter Experts. His starting point is the brief Use Case description in the Use Case Model, together with relevant user interface and navigation guidelines found in the Navigation Map. We briefly introduced these work products in the blog post Gather Requirements the Agile Way and treat them more fully in an upcomming blog post No Magic. Assume for this moment that they, as the phrasing is, ‘magically appear’.
Figure 35: Preparation Workflow – scenarios |