Friday, December 30, 2011

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

Monday, December 19, 2011

Experience the Product

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

We now take a closer look at the accepting side of the process. Since software delivery is a cyclic process, acceptance is conducted in a cyclic manner as well. Although Subject Matter Experts and the Product Owner have already been involved in the software development cycle, it is now time for the accepting organization to have a thorough look at the increment built and to get stakeholders (customer, users, administrators) to experience and familiarize themselves with the product and give feedback on it.

In Figure 46 and Figure 47 we build up a workflow explaining a RUP based process of getting the product accepted and the receiving organization to familiarize themselves with it. A key to the symbols used in this workflow can be found here.



Figure 46: Acceptance Workflow – install the Product

Monday, December 12, 2011

Get Things Done

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

To get a story done it has to be implemented and as near to production quality as the team can get it. For this the team has to build software and test it. Scrum provides little guidance for the team on how to do that accept for saying the team has to self-organize. XP provides a set of day-to-day practices and stresses that the team as a whole should feel responsible for the Sprint result. This still means the team has to devide tasks in a way that ensures that the customer will get the most value out of each working day.

In Figure 41 through Figure 43 we build up a workflow explaining a RUP based process of software development and testing you can follow to get a Usable Increment done. A key to the symbols used in this workflow can be found in here.



Input to this workflow is an agreed set of Use Cases or Use Case scenarios that are pokered and forecasted to be done by the end of this Sprint.
Figure 41: Development Workflow -- implementing