Personal Finance Manager Epics & Stories (Part Two)

Content

PFM Epics & Stories

Summary

On the previous page we discussed the Agile methodology for developing or maintaining a Product. From the diagram shown on the page it could be seen that the requirements are represented by User Stories and all uncompleted Stories represent the work backlog. If you would like to learn more about the Agile/Scrum methodology just google it there is a lot of information on the Web. We will use the Agile/Scrum methodology albeit pretty loosely to develop the PFM application.

Specifying Epics & Stories

In the Scrum world an Epic is defined as a something that is bigger than a User Story, and that will span multiple Sprints. So to manage our project I will define some Epics now that help to manage our work backlog across Sprints. I will also define some Epics that I have not seen in the Scrum world but which are essential to the development of robust software.

The recommended template for User Stories is

As a <user role>, I want to <goal> so that <benefit>

So then lets make a start by taking another look at our Product Statement from the previous page.

Personal Finance Manager is a software product for managing personal finances. It will allow the user to enter bank accounts and transactions, provide categories and reports to show the status of the managed personal finances.

From the 'Product Statement' we can extract the following nouns for our database entities. At a first pass we find the following...

  • User
  • Bank Accounts
  • Transactions
  • Categories
  • Reports
Instead of 'User' we will use 'Owner' as bank accounts usually have an owner associated with them. For each item in the list we would like to perform CRUD operations (Create,Read,Update,Delete) which leads to the following Epics for each entity. Of course each Epic will be broken down further into User Stories.
  1. Epic Entity CRUD Operations

    1. As a PFM APPLICATION USER, I want to CREATE/READ/UPDATE/DELETE ACCOUNT OWNERS so that ACCOUNT OWNERS CAN BE MANAGED.
    2. As a ACCOUNT OWNER, I want to CREATE/READ/UPDATE/DELETE ACCOUNTS so that BANK ACCOUNTS CAN BE ASSIGNED TO OWNERS.
    3. As a ACCOUNT OWNER, I want to CREATE/READ/UPDATE/DELETE TRANSACTIONS so that TRANSACTION AMOUNTS ARE RECORDED FOR THE ACCOUNT THEY ARE ASSIGNED TO.
    4. As a ACCOUNT OWNER, I want to CREATE/READ/UPDATE/DELETE CATEGORIES so that TRANSACTIONS CAN BE CATAGORISED ACCORDING TO THEIR TYPES.
  2. Epic PFM Reporting

    As an ACCOUNT OWNER, I want to GENERATE REPORTS BASED UPON THE BANK ACCOUNT TRANSACTION CATEGORIES so that I CAN VIEW GRAPHICALLY HOW MY FINANCES ARE BEING USED
  3. Epic Web Application
    We would like to present a view on the PFM product as a web application so...

    As a PRODUCT OWNER, I want to PRESENT THE NEW PFM PRODUCT AS A WEB APPLICATION so that USERS CAN USE THE PRODUCT WITHIN THE FAMILIAR ENVIRONMENT OF A WEB BROWSER
  4. Epic Software Configuration Management

    As a CONFIGURATION MANAGER, I want to MANAGE THE DEVELOPMENT OF PFM so that VERSIONS AND FEATURE BRANCHES ARE MANAGED USING VERSION CONTROL SOFTWARE THAT PROVIDES FOR SOFTWARE CONFIGURATION MANAGEMENT
  5. Epic Quality Metrics & Code Quality

    As a QUALITY MANAGER, I want to ENSURE THAT GUIDELINES AND DEFINED QUALITY METRICS ARE EMPLOYED so that I can MONITOR THE QUALITY OF THE PFM APPLICATION

So we now have a set of Epics that are written down and ready to be expanded into User Stories. Its important to make a start in this way and during team meetings each Epic can be discussed and analysed further. Be careful not to over analyse at this stage, I have worked on projects where so much time and project budget is burned on trying to analyse each and every detail with no real progress made.

The Epics are top level containers for our work backlog that will be further refined.

Acceptance Stories

The recommended User Story template shown at the top of this page says nothing about how the Story will be tested for suitability. As an addition to the User Story the acceptance criteria will be written as an 'Acceptance Story' and added to the User Story, the following template serves our purposes.

Scenario 1: Title
Given <context>
And <some more context>
When <event>
Then <outcome>
And <another outcome>
For the Create New Account Owner the 'Acceptance Story' is written as...

Scenario 1:  Create New Account
Given that the new Account Owner does not already exist in PFM
And and the required fields are entered with valid information
When the application user saves the New Account Owner
Then the application will assign a unique id and persist the Account Owner entity
And the new Account Owner information will displayed.

Defining Sprint One

So lets make a start on defining the first Sprint of work by adding some Stories to the Epics above and working on them in a short development cycle.

For the first Sprint we will add some Stories and to these Epics. We also add some tasks to the User Stories.

  1. Epic Entity CRUD Operations
    The first Sprint will will expand the Epic CRUD Operations for the Account Owners as shown in 1a above.

    Epic 1a Account Owners CRUD

    As a PFM APPLICATION USER, I want to CREATE/READ/UPDATE/DELETE ACCOUNT OWNERS so that ACCOUNT OWNERS CAN BE MANAGED.

    User Stories

    1. Create New Account Owner
      As a PFM APPLICATION USER, I want to CREATE ACCOUNT OWNERS so that ACCOUNT OWNERS ARE PERSISTED WITHIN PFM
      Acceptance Criteria 1
      Given that the new Account Owner does not already exist in PFM
      And and the required fields are entered with valid information
      When the application user saves the New Account Owner
      Then the application will assign a unique id and persist the Account Owner entity
      And the new Account Owner information will displayed.
      		
    2. Read Account Owner Information
      As a PFM APPLICATION USER, I want to VIEW AN ACCOUNT OWNER so that I CAN VERIFY THE ACCOUNT OWNER INFORMATION
      Acceptance Criteria 1
      Given that the new Account Owner exists in PFM
      When the Account Owner ID is entered
      Then the application will display the Account Owners information
      		
    3. Update Account Owner
      As a PFM APPLICATION USER, I want to EDIT/UPDATE AN ACCOUNT OWNER so that I CAN MOFIFY THE ACCOUNT OWNER INFORMATION
      Acceptance Criteria 1
      Given that the new Account Owner exists in PFM
      When the Account Owner ID is entered
      Then the application will display the Account Owners information
      And allow the currently stored information to be modified
      When the user saves the new information it will be persisted
      And the new Account Owner information will be displayed
      		
    4. Delete Owner
      As a PFM APPLICATION USER, I want to DELETE AN ACCOUNT OWNER so that I CAN REMOVE ACCOUNT OWNERS FROM PFM
      Acceptance Criteria 1
      Given that the new Account Owner exists in PFM
      And there are no Accounts linked to the Owner
      When the Account Owner ID is entered
      Then the application will request confirmation
      And when the confirmation is confirmed the Account Owner will be deleted from PFM
      		

    Tasks

    1. Create a UML model of the PFM domain entities
    2. Create a maven project for the application domain entities
    3. Create a maven project for the persistance layer
  1. Epic Software Configuration Management

    Epic 1a Account Owners CRUD

    Epic Tasks

    1. Set up Git and add application domain maven project contents
    2. Create a feature branch for developement of Owner Entity CRUD operations
  1. Epic Quality Metrics & Code Quality

    Epic 1a Account Owners CRUD

    Epic Tasks

    1. Create auto-generated HTML reports for all Unit tests
    2. Create auto-generated HTML reports for Unit tests code coverage
    3. Create auto-generated HTML reports for coding guideline violations

    With our first Sprint defined we can now make a start on the PFM aplication. Click the arrow below to navigate to the implementation of Sprint One.

Date Entered2014-06-08