The Product Backlog

In any software product development the most important thing to start with (if it is a new product) or to always have (if it is an existing product) is a Product Backlog.

The product backlog really encapsulate your high-level product vision to all people participating in the product's development life cycle. So what is the definition of a product vision? It is: what is the objective of the software product, what is the features offered by the software product, what is the roadmap of the software product, what will we focus on next during the product development, what is the business value of features on the product backlog, what else besides functionality features needs to be delivered to make the product)

I would say it is important to put in effort to write proper stories on the product backlog, using the right format for writing these stories, as it will save you time and money later in that: 1. people have a better understanding of the feature, 2. You do not have to redo the feature later into a proper format, 3. functionality and all related tasks needed to deliver the software is communicated in a consistent way, 4. you started writing your spec already.

A proper story would look as follows:

Feature: Write a product backlog

In order to build the ... software (business value)

As a ... Product Owner (role/user/system)

I want to pin down all the current high-level product features (requirement) So on the product backlog you will only have the details of the story. Scenarios will be made available for each sprint to the team as part of the sprint planning, to provide more detail on exactly what needs to be delivered. The scenarios will then be used to do estimation during sprint planning. A Scenario will look as follows: Given ... (input) And ... And ... When ... (event) Then ... (outcome) And ... And ...

Download Product Backlog template: http://www.taniavanwykdevries.co.za/Downloads/ProductBacklogTemplate.xlsx

Testing policy in SCRUM

• The first 2 stories already exist and have been delivered in previous releases.
• Story number 3 and 4 is new stories and is a deliverable in the current release.
• Story 1 and 2 is related to stories 3 and 4.
• Internal testing includes: stories, story tests, unit tests, functional test packs, regression test packs
• All testing artifacts are stored in subversion.
• Stories, story tests and unit tests are stored with the code.
• Functional test packs, regression test packs are stored in a testing project in subversion.
• Working internal test packs are stored under the relevant business context: “Testing/Context/Context1”
• If an internal test pack is used during a release, test results are recorded and stored under a “Release” directory in subversion.
• The Tester and the Product Owner sign off the last version of an internal test pack internally. The Tester then scans the signed off pack in and upload to subversion under a “Release”.
• The Delivery team prepares the Acceptance Test Packs. This is handed over to the Client, together with the
• The Product Owner, Client Side Representative and Client sign off Acceptance Test Packs. The signed copies are scanned in and send to the Tester. The Tester stores the signed off copy in subversion under a “Release”.

Definitions

Functional testing: quality assurance within the delivery team, focused on testing user stories delivered during the current release.

Regression testing: quality assurance within the delivery team, focused on testing user stories that are related to stories delivered during the current release cycle. It also focused on grey box and black box testing. Examples: 1. From UI down to database; 2. Across infrastructure software: ftp => application server  => application server =>; message queue => message queue database

Acceptance testing: is conducted by the Product Owner, Client Side Representative and the Client to verify that the stories delivered during the release, meets expressed requirements.

Sprint Retrospective

• Timebox: 2 hrs for 2 week sprint.
• Should be done before the next sprint planning session.
• Evaluate: 1. what worked 2. what did not work.
• Each team member has a stack of post-its and write down items of 1 & 2 above.
• Items relating to 1 & 2 is then put up in different corners of the room.
• This process continues till everyone has written down everything that comes to mind.
• 1 person in the team picks a item to start with and it is discussed amongst the team.
• Actions are identified for each item.
• These items are added to the product backlog for the next sprint with a story point value, so that the team gets time to work on the improvements.
• On 2 items: also focus on how do we continue to make this work. Write down some ideas.
• When evaluating items think about: people, relationships, process and tools. Some examples as per the scrum guide: team composition, meeting arrangements, tools, definition of "done," methods of communication, and processes for turning Product Backlog items into something "done."