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
The Product Increment is deployed in the Staging environment of the Customer, in order to subject it to a set of tests the Customer organization has prepared.
Figure 47: Acceptance Workflow – test the Product
 Once deployed, the Product Increment is ready to go through a set of tests, executed by the customer. Typically, a functional acceptance test and a user acceptance test are performed. The former is a test in which the functionality is formally checked against the Use Case and acceptance criteria from the Product Acceptance Plan. The latter is a test in which end users and system administrators, typically including the designated Subject Matter Expert, check whether the Increment is what was intended, facilitated by an Acceptance Tester.

New or changed insights concerning the deployment procedure are recorded in the System Administration Documentation, in order to have an up-to-date deployment procedure. This procedure is tested every time a new increment is deployed. At this point information needed in the maintenance lifecycle of the product is also developed and if necessary, augmented or changed.

Half way the next Sprint at the latest acceptance of the Sprint result is communicated by the Customer. This may include reports of found off-specs and other findings to be solved and the condition that they are fixed or put into the Product Backlog. If reported early enough the team does its best to have all smaller issues (that don’t interfere with their forecast) fixed before the next Demo. Bigger issues go to the Product Backlog. If the Customer does not react within this term, the Increment is implicitly accepted. Later findings automatically go to the Product Backlog. In this way, cyclic customer collaboration is stimulated.

Figure 48 gives an overview of stakeholder roles and team roles and the work products they collaborate on to get stakeholders (customer, users, administrators) to experience and familiarize themselves with the product.
Figure 48: Acceptance Collaboration Matrix
Figure 49 positions the Acceptance Workflow relative to an outline of the Scrum process.

Figure 49: Positioning the Acceptance Workflow

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 4 of this post is Iterations in Time.

3 comments:

  1. Hey There. I found your blog using msn. This is a very well written article. I’ll be sure to bookmark it and come back to read more of your useful info. Thanks for the post. I’ll definitely return 먹튀검증사이트

    ReplyDelete
  2. Thanks for this wonderful information. You posts are really nice and interesting. Writing style is also very amazing how to play pokemon games on iPhone

    ReplyDelete