Iterations in Time

This is part 4 of 4 of a post on how to iterate in RUP. The introduction to this post can be found at ScrumUP Fairytale - Part 4.

By now we are able to see how the content of several Sprints hangs together. In the Preparation Workflow, the Team prepares to get Stories ready for development. The Planning Meeting and subsequent development of a story starts before preparation is complete. Before the Planning Meeting just enough preparation is done for the team to be able to Poker the Story. In early development Subject Matter Experts look at the solution under construction and fill in details where needed. Development starts before requirements are complete.
Figure 13 shows that the Team works together in two subsequent Sprints: the first for getting Ready, the next for getting things Done. To finish the cyclic process, the customer accepts the team’s work in the Sprint directly subsequent to Development. Hence, in one Sprint your Team has to spend time to prepare next Sprint, get the items for this Sprint Done and support acceptance activities.

Figure 50: Sprints and workflows in time

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

Other Relevant Posts:
Maintain Stability using XP

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

Gather Requirements the Agile Way

In the post Self-organize using Scrum we saw that Scrum supposes that the Product Owner can fill the Product Backlog with stories, ordered by the desired sequence of implementation. Furthermore Scrum supposes that the team estimates these stories and comes up with a Definition of Done that will ensure a common understanding of the desired quality constraints. It doesn’t say where the information comes from that is needed to do these things. Speaking with Jeff Sutherland (one of the founders of Scrum) – “this stuff magically appears”. In this section we will look at the way Agile requirements practices can help in this regard.