Agile	ID	Parent	User Story
`epic`	`epic(chart-card-view)`		As a User, I want a Chart Card View
`epic`	`epic(card-view)`	`epic(chart-card-view)`	As a User, I want a Card View
`user story`	`feat(card-view-header)`	`epic(card-view)`	As a User, I want a Card View Header
`user story`	`feat(card-view-header-min)`	`epic(card-view)`	As a User, I want a minimize button
`epic`	`epic(chart-view)`	`epic(chart-view)`	As a User, I want a Chart View

Template

Card View

Let's go ahead and create the Card view like the design below:

Question: Do you want to follow full Agile project management practice or just show the code
1. Agile 
2. Code only

Approach

There's quite alot going on here so let's break this into 2 major components:

The Card View
The Chart View

The Card View can be reused in multiple places so it makes sense as a reusable component.

The Card View can be futher componentised into

Header
Content, and
Footer

like so

Let's spec this up using Agile project management framework.

#Agile In Agile the main deliverable unit of work is called a "User Story".

Its purpose is to articulate how a software feature will provide value to the customer.

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.

Since our Chart View feature has multiple components, we'll break it down like so:

Component	Agile term
`Chart Card`	Epic
`Chart Component`	User Story
`Card Component`	User Story
`Card Header`	Sub task
`Card Content`	Sub task
`Card Footer`	Sub task
`Card Actions`	User Stories

Note!

Now in practice Product Owners, Agile Evangelists and Scrum Masters agonise over the definition of what is and isn't an epic, user story or feature and how these map to features, components and shippable software. We are going to introduce you to the apporach we use at master-class.io so you can see a system that works for us. Every organisation is different - take what works, discard what doesn't for your team, and keep learning and adapting! ... sermon over

Epics

An "Epic" is a large body of work that can be broken down into a number of smaller user stories which we'll cover soon.

Every company has different definitions of what is an Epic or a User Story, so I'll show you what we use at master-class.io.

For us, any feature that has multiple components that can be broken up into more shippable units of customer value is an Epic. Any shippable feature that enhances the user experience on its own, is a User Story.

In our example, the entire Chart Card is the Epic.

At master-class.io we attempt to word everything, including epics, using the parlance: As a {user}, I want {feature, so that {benefit}

In our example, As a User, I want a Chart Card, so that I can get a quick snapshot of my profitability for the quarter

User Story

In Agile the main deliverable unit of work is called a "User Story".

Its purpose is to articulate how a software feature will provide value to the customer.

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.

Note!

Honestly, you will get over the endless debate of this fairly ambiguous definition so again, for us at master-class.io we use the following rule of thumb, the Minimal Shippable Value test:

If this mini feature popped up live on the End User's screen, would it add value?

For example, on an e-commerce store, a button to "save to wishlist" would only add value if you clicked it and it actually worked.

Accordingly, we don't seperate User Stories into "Frontend", "Backend", but rather the "smallest thing that works". A Minimal Viable Product of you will on the smallest scale possible.

This may mean adding placeholder functionality even if there's a little overhead with refactoring.

Example of a User Story

Let's use Instagram as an example. A post has a card (similar to our design) with a carousel of images, some buttons to like/love, and comments section. Naturally we would want to ship the Card with a picture and title as a minimum. But we dont need the full carousel. So our User Stories would be: epic: As a User I want a Post with an Image Carousel, Buttons Menu and Comments section

As a User, I want to see a Card with a Title, Date, Picture and description
As a User, I want to be able to love a User's post
As a User, I want to be able to delete my post
As a User, I want to see a Card with an image carousel

This also allows us to postpone anything not MVP to a later sprint. e.g. As a User, I want to see a Card with an image carousel could wait till next sprint and still be valuable to the end user with just the image for now.

This is far superior to

As a User, I want an Image on the frontend
As a User, I want to load the Image from an API or CDN

Mostly because thats not (likely to be) what our target persona would ever ask for any feature related to the API. Furthermore, it fails the minimal shippable value test - a placeholder image popping up on the production app would be weird for the end user

Card View

Card View: User Story

...back to our example

On our Kanban board let's create our first user story for the Card View.

As a User, I want a Card Layout, so that I can keep my Dashboard neatly organised.

It's a bit forced but this contract helps keep the business, design and tech teams aligned. So let's just roll with it...

Let's add a wireframe to help our team understand this story, as they say, "a picture is worth a 1000 words"

@todo - add trello card

Card View: Design

Now we can add our Design. A Designer will typically use a tool like Sketch or Adobe XD

Let's create the following design and add it to the kanban card.

@todo - add sketch design

{
    design: {
        trelloCardId: 1, 
        layers: [
            {
                id: 1,
                name: 'background',
                zIndex: 0
            },
            {
                id: 2,
                name: 'axis',
                zIndex: 1
            },
            {
                id: 3,
                name: 'bars',
                zIndex: 2
            },
            {
                id: 4,
                name: 'legend',
                zIndex: 3
            }
        ],
        components: [
            {
                parentLayerId: 3, 
                type: 'bar',
                styles: {
                    border: '1px solid  purple',
                    background: 'rgba(255,255,0,.3)'
                },
                box: {
                    bottom: '20px',
                    left: '50px',
                    width: '20px',
                    height: '100px'
                }
            }
        ]
    }
}

Estimates

Following the agile SCRUM methodolody before each sprint we have a 2 hour meeting called "Backlog Grooming". During this meeting the 👨‍💻 Product Owner will prioritise which user stories have the most value. After that the team as a group will estimate the effort required to deliver the user story.

We use a technique called "Planning Poker". This method

Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.

Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.

Card View - Estimates

Let's say after a few rounds the team agrees the Card View is a simple story.

It only requires frontend React code and some styling using the material ui library

We will estimate this as 3 points or "small"

Test Driven Development (TDD) and Behaviour Driven Development (BDD)

Test driven development (TDD) is an software development approach in which a test is written before writing the code. Once the new code passes the test, it is refactored to an acceptable standard.

TDD ensures that the source code is thoroughly unit tested and leads to modularized, flexible and extensible code. It focuses on writing only the code necessary to pass tests, making the design simple and clear.

TDD Cycle

Let’s start with the basics and have a look at the TDD cycle, also know as Red-Green-Refactor process, step by step.

The Test-Driven Development cycle:

Add a test, which will certainly FAIL. (Red)

In TDD, every feature in a software is first added in terms of test cases. A test is created for a new or updated function. To write the tests, developers must understand the feature specifications and requirements.

This practice separates TDD from traditional software development methods where unit tests are written after writing source code. In this way, TDD makes the developer focus on the requirements before writing the code.

Run all the tests. See if any test fails.

Running tests validates that the test harness is working correctly and simultaneously proves that as new tests added are failing with the existing code, new code is required.

Write only enough code to pass all the tests. (Green)

The new code written in this stage may not be perfect and may pass the test in an irrelevant way. The only requirement in this stage is that all the tests should pass. One possible way to begin with adding the statements is to return a constant, and incrementally add logical blocks to build the function.

Run all the tests. If any test fails, go back to step 3. Otherwise, continue.

If all the tests pass, it can be said that the code meets the test requirements and does not degrade any existing features. If any test fails, the code must be edited to ensure that all the tests pass.

Refactor the code. (Refactor)

As the code base grows, it must be cleaned up and maintained regularly. How? There are a few ways:

New code that might have been added for convenience to pass a test can be moved to its logical place in the code. Duplication must be eliminated. Object definitions and names must be set to represent their purpose and usage. As more features are added, functions become lengthy. It can prove beneficial to split and carefully named to improve readability and maintainability. As all tests are re-run throughout the refactoring phase, the developer can be confident that the process does not alter any existing functionality. 6. If a new test is added, repeat from step 1.

Take small steps, targeting as few as 1 to 10 edits between each test run.

If the new code does not quickly satisfy a new test, or other unrelated tests fail unexpectedly, then undo/revert to a working code, instead of doing extensive debugging.

Card View - TDD

Enough theory, let's do this...

Let's review our Definition of Done (DoD) for our User Stories

TDD is an opportunity to create a very clear checklist of tests to prove that this story is indeed "Done"

feat(min-card): As A User, I want to minimise the card
- [x] should show a min icon
- [ ] should close the card contents when i click the min button
feat(close-card):As A User, I want to close the chart card
- [ ] should show a close icon
- [ ] should close the card when i click the close button
feat(revenue-chart):As A User, I want a revenue chart
- [ ] should show a bar chart
- [ ] should update when I change the date range

Unit Tests

Writing these as test stubs we would do the following:

[ ] create a new folder for our component /components/card
[ ] create a new test file in this folder called /components/card/card.test.tsx
[ ] Write the unit test stub using jest syntax

describe('As A User, I want to minimise the card', ()=>{
    describe('#feat(min-card-button)', ()=>{
        
        it('should show a min icon', ()=>{

        })
        it('should close the card contents when i click the min button ', ()=>{
            
        })

    })
})

Note the describe block "describes" the suite of tests we ant to run. We can have nested suites. In our example, we have described the user story suite and the feature suite for the actual button component we are going to build. This is not typical but how we do it at master-class.io for ultimate user story alignment. Remeber - adapt what works, discard what doesn't...

The it block is a human readable description of what functionality or criteria we are testing. As per our DoD, it should show the min icon.

Let's install jest and run the stub before implementing the red/failing test

Install Jest

In the cli

yarn add -D jest @types/jest

Update the package.json to give us a simple shortcut

{
    "scripts": {
        // ... add this ... 
        "test": "jest"
    }
}

and run the unit test from the cli with the command:

yarn test

We shoudl see the following placeholder results:

mightyhorst/Template.Component.mdx

Select an option

No results found

Select an option

No results found

Template

Accounting Page - Agile and User Stories

Revenue Chart Card - Agile and User Stories

Boner

Template

Card View

Approach

Note!

Epics

User Story

Note!

Example of a User Story

Card View

Card View: User Story

Card View: Design

Estimates

Card View - Estimates

Test Driven Development (TDD) and Behaviour Driven Development (BDD)

TDD Cycle

Card View - TDD

Unit Tests

Install Jest