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

The Developer starts with a story on top of the Sprint Backlog. Any Working Software he builds or changes is code-documented and furnished with relevant programmer tests, conforming to the team’s Definition of Done. It is a very good idea to have several unofficial demos during implementation. This way, Subject Matter Expert, Analyst, Tester and other team members have a natural and low-ceremony overview and can detect possible misunderstandings. This increases the quality and decreases the chance of findings (leading to rework and test effort) later on in the Sprint or thereafter.

Figure 42: Development Workflow – testing

The Tester tests using the test cases prepared in the foregoing Sprint as soon as the Developer indicates the code is mature enough to do so. The Subject Matter Expert participates in this activity. Any findings are passed to the Developer and fixed in that Sprint whenever possible. Also, easy to fix Acceptance Findings reported during the Acceptance period are taken care of as soon as possible. Bigger, more structural Acceptance Findings are added to the Product Backlog.

Figure 41: Development Workflow – Delivering

Toward the end of the Sprint, the Tester summarizes the testing efforts and his view on the readiness of the implemented stories in a Test Report. The Developer prepares a Usable Increment, with Release Notes and relevant System Administration Documentation. Progress is measured in stories that are done and delivered as part of that Usable Increment.

Figure 44 gives an overview of stakeholder roles and team roles and the work products they collaborate on to get a Usable Increment done.

Figure 44: Development Collaboration Matrix

As shown in Figure 45 only Stories that conform to the Definition of Done are built into the Product and shown at the Demo that takes place at the end of the Sprint. In this way, it is always clear what the quality of the Product Increment is. ‘Done’ is quite a meaningful word in Scrum.

Figure 45: Positioning the Development Workflow

At this Demo at least the Product Owner and Subject Matter Experts are present. The Product Owner can however invite any stakeholder to see the Sprint result and this way manage expectations. This Demo plays an important part in the acceptance (both emotional and official) of the Product.

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

Other Relevant Posts:
Be Transparent