Get Ready to Poker

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 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

The first sessions on a particular Use Case is devoted to the goal of the Use Case (Scenario) at hand and the steps the actor envisions in order to reach that goal. After this session, the Analyst and the Developer work together in making a screen prototype that reflects the input of the Subject Matter Experts. When this screen prototype is presented in the second session and the Subject Matter Experts actually see what they have told the Analyst, more often than not they see what they have taken for granted, omitted or just did not think of. In our experience, this second session is the most exciting as well as the most fruitful. It is one thing to have discussed a scenario, but quite another to have the corresponding screens which you can walk through. To almost anyone, a ‘live’ screen with actual information tells much more than the same information in a descriptive form.

Figure 36: Preparation Workflow – test cases

In parallel the Tester cooperates with the Analyst and Subject Matter Experts to obtain testable Use Case Scenarios. Writing Test Cases for these scenarios helps him find any indistinctness and determine the testability of the Use Case. The Test Cases are written with the acceptance criteria from the Product Acceptance Plan in mind.

Figure 37: Preparation Workflow – design

The Developer walks through the Scenarios, together with the Analyst, to see how it is to be realized in code and to discuss any issues. This may result in changes in the Use Case. A change in this respect ensures that the Use Case can be built with reasonable effort. The Developer of course consults the Software Architect if he has any hesitations about how the architecture should be implemented. The Developer updates the Design to reflect additions or changes made for this Use Case and starts implementing developer tests in the Test Suite for this Use Case.

Figure 38: Preparation Workflow – agreement

Finally, the Product Owner makes sure that all stakeholders agree on the scenarios and that the Team is ready to start developing these.

Figure 39 gives an overview of stakeholder roles and team roles and the work products they collaborate on to get the team ready to poker.

Figure 39: Preparation Collaboration Matrix

If you think by now: okay, but this is just too much, in our team we reach the Ready to Poker state in a 20 minutes conversation, and that’s it – this is fine. It means that your ‘level of ceremony’ is a bit lower than sketched above. In the meantime, in this 20 minutes conversation you will probably recognize both the roles and the goal mentioned above.

Figure 40 positions the Preparation Workflow within the cyclic Scrum process. It shows that before a Sprint starts, just enough of this workflow is executed for the team to get Ready to Poker. This means just enough information is gathered to be able to estimate the Stories for this Sprint and give commitment for their development. Execution of the workflow continues after Sprint Planning, parallel to the early development of the Stories.

Figure 40: Positioning the Preparation Workflow

The introduction to this post can be found at ScrumUP Fairytale - Part 4
Part 2 of this post is Get Things Done.
Part 3 of this post is Experience the Product.
Part 4 of this post is Iterations in Time.

Other Relevant Posts:
Gather Requirements the Agile Way
Be Transparent