SrrTrains Core Team - PM Stuff

The Product Backlog - PBL

The product backlog shows all "old", "current" and "pending" user stories.

If you like to know, what a user story is, please visit the PM – Glossary below.

PM - Glossary

Steps

SrrTrains software is developed in what we call "steps". The basic idea is to finish SrrTrains v0.01 within 100 steps, so that "step 0100" would be the last step of achieving SrrTrains v0.01.

Until our first test session, which we called "LAN – Party #1", the software had undergone 32 steps of development, the next "step 0033" has been given the title "Re-Design after First LAN Party".

However, the "step 0033" had proven to be the biggest step so far, thus we were forced to split "step 0033" into sub-steps, "step 0033.01", "step 0033.02" and so on.

Currently (as of March 2020) the project is STUCK IN 2ND HIBERNATION after a long phase of 1st hibernation and waiting for third party interest, which could RE-OPEN the project, if at all.

User Stories

User stories are representations of wishes of actual or potential users of SrrTrains software.

The project admin is in charge to collect users' wishes and to phrase user stories in the product backlog.

When phrasing a user story, the project admin should check, if the story is already covered by one or more change requests of the product data base. If the user story is not (completely) covered, then the project admin should consult the architect and define one or more new change requests.

Project Admin

The project admin administrates the following projects:

The project admin has got access to all data of the projects.

The project admin can add and remove users to/from the projects.

Current project admin:

Dipl.-Ing. Christoph VALENTIN
mail: christoph[dot]valentin[at]gmx[dot]at
address: Brunhildengasse 3/3/19, 1150 Wien, Austria.

Product Backlog

The product backlog is a simple table that holds requestor, title and description of all user stories.

When a user story has been considered within a step of development – when the user story is released –, then the project admin moves the user story from the "pending" user stories to the "current" user stories.

"Current" (or "pending") user stories may be moved to "old" user stories as appropriate (e.g., when nobody is interested to listen to this story any more).

Change Request / Reason for Change

User stories of the product backlog can be mapped to change requests of the product data base.

Where user stories are the "raw" description of the users' wishes, change requests on the other hand are the "elaborated" description of howto achieve the fulfillment of the users' wishes.

Change requests are the result of project internal discussion and can hence describe in a more distinct way, what the developers should do to achieve the fulfillment of the users' wishes.

On the one hand, the users don't need to know the change requests, on the other hand the project members should know the user stories in addition to their change requests.

Product Data Base

The product data base is a project internal resource of information.

On the one hand, the processing of the users' input (the user stories) leads to the creation of change requests in the product data base and to the creation of pending components and of pending features.

On the other hand, the processing of the change requests leads to changes of the existing features and to changes of the existing components, as well as to the creation of features and of components from the pending features and components.

In an ideal environment, the product data base would tell us, why and when which part of the product was changed in which way. It's especially the "why", which makes the product data base necessary.

Components and Features

Components and features are the "objects" of the project data base. "Com-ponere" is Latin and means something like "to put together".

Hence a component is one of the parts of the product that can be put together to build a release of the product.

Features on the other hand tell us, "what we can do" with the product. A feature is a description of a precious quality of the product.

To give an example: if our product was a car, then a wheel or a door would be a component of the car, on the other hand the possibility to move goods of x kg from A to B would be a feature.

Pending Components and Features

The product data base lists not only components and features that have already been implemented, but it lists also components and features that are foreseen for the future of the product. Such future components or features are called "pending" components or features.

PM – Procedures

Continuous Updates

The project admin is responsible, to keep following resources of the world wide web up to date in a continuous manner

  1. The "Home of SrrTrains" at members.chello.at/christoph.valentin
  2. The project WEB at simulrr.sourceforge.net and at smuos.sourceforge.net

This includes the Product Backlog (PBL) and the Project Follow Ups (PFUs).

The project admin is responsible to listen to users' wishes continuously.

Users' wishes should be collected in the product backlog in a most authentic way (e.g. taking received e mails with copy&paste, e.g. wordly citing from forum discussions, and so on)

The project admin is responsible to discuss users' wishes with the architect and to define pending change requests, pending components and pending features in the product data base

The project admin is responsible for the administration of the sourceforge projects, this includes adding and removing of users to and from the projects, respectively.

Initiating a Step

The project admin is responsible to take change requests from the pending change requests of the product data base for this step.

I.e., the "target release" in the product data base is set for all change requests that should be handled in this step.

Change requests may be split into process steps.

All change requests and all process steps selected for this step are documented in the PFUs.

While a Step Is Ongoing

If a developer takes a change request, then the project admin is responsible to set the "reason responsible" for this change request in the product data base.

The project admin is responsible to update the PFUs, when a change request has been finished.

Closing a Step

When a step has been finished, then the project admin is responsible to check the contents of the product data base.

The project admin generates the .pdf files from the product data base and adds them to the release.

The project admin is responsible for the release notes and he gives the "final GO" for a release.

Closing Remarks

a.m.D.g.