Amee product development workflow

Product Management at AMEE

Friday, 26 October 12

Clear, visible process across the company

Measurable value from development

Lightweight, easily adaptable to future change.


Bugs

Ideas DevelopmentPlanning

Roadmap

Measure


Bugs


Roadmap

Ideas

RoadmapCompany strategy, defined in terms of high level requirements, or high level themes for user stories.

Suggestions for the product come from inside the company, or from external sources, like customer service channels, or any external forums for discussion of the product.

BugsDefects in the product as reported by customers or staff, or issues raised by any error logging tools.


Bugs


Roadmap

Planning

Input from each board has a qualifying process before it makes it to planning.

Bugs are confirmed as reproducible, Ideas are described in enough detail to be understood by a product manager Items on the roadmap are confirmed as still relevant to the company strategy.

Requirements or draft stories are fleshed out here, with sketches or wireframes, until they are in a state that can be estimated upon by a development team, and delivered.


Bugs


Roadmap

Planning

EstimationMeeting

Developer Review


Bugs


Roadmap

Planning

EstimationMeeting

Developer Review

One developer and the product manager reviews any story or requirement that needs an estimate in this meeting. Together they weed out technical issues, and dependencies before a group estimation, or identify areas that need further definition before estimation is possible.


Bugs


Roadmap

Planning

EstimationMeeting

Developer Review

In an estimation meeting the developers, and the product manager run through the stories and allocate a points value to each story based on perceived difficulty across the whole team.


Bugs


Roadmap

Sprint planning and development

Daily Standup

Sprint planning

Retro-spective

Sprint Demo


Bugs


Roadmap


Stories and requirements are assigned to a sprint in a sprint planning meeting. A product manager reviews the stories going into the sprint with the development team, and the development team commit to delivering the work, based on the velocity agreed in the last sprint retrospective.

Daily Standup

Sprint planning

Retro-spective

Sprint Demo


Bugs


Roadmap


Every morning, the development team and the product manager runs a 15 min stand-up meeting, answering the following questions:- What you did yesterday?- What are doing today?- What is blocking you?Sprint progress is reviewed, against what was committed to for the sprint.

Daily Standup

Sprint planning

Retro-spective

Sprint Demo


Bugs


Roadmap


On the last day of the sprint, the team members run through the work they’ve completed to the rest of the team, and the product manager.Original ‘owners’ of an idea are optionally present, to see the requested story delivered.

Daily Standup

Sprint planning

Retro-spective

Sprint Demo


Bugs


Roadmap


After the sprint demo, comes the retrospective. The team discusses the good and bad aspects of the sprint, and any changes to their process they’d like see internally.The team commit to a velocity for the next sprint, based on the points delivered, to help plan the next sprint.

Daily Standup

Sprint planning

Retro-spective

Sprint Demo


Bugs


Roadmap


What this looks like in Trello


Bugs


Roadmap

Filing bugsFriday, 26 October 12

Bugs


Roadmap

Inbox Reviewed & needs input Accepted

Bug with description


Bugs


Roadmap

Inbox Reviewed & needs input Accepted

Bug with description, and

steps to reproduce, etc.


Bugs


Roadmap

Collecting IdeasFriday, 26 October 12

Bugs


Roadmap

Awaiting Review Under review Accepted

Idea from inside the company

External customer request

Ideas come from any where inside, and outside the company


Bugs


Roadmap




A product manager works with the originator, to flesh them out.


Bugs


Roadmap




When it’s understood, it can be moved to the planning board


Bugs


Roadmap

How the roadmap drives product


To avoid waste, user stories and features only become more detailed and granular as they get closer to development.

Now

Future


Bugs


Roadmap

Q3 Q4 2013

Update sign-in process

Defined and documented API

RAG status on suppliers

Public sign-in for companies

Scope 3 calculation

CRC Reporting

The Roadmap gives a high level view of areas of focus in coming months.


Bugs


Roadmap

Q3 Q4 2013

Update sign-in process

Defined and documented API

RAG status on suppliers

Public sign-in for companies

Scope 3 calculation

CRC Reporting

New cards are created based on these themes in planning


Bugs


Roadmap

Defining deliverable work


DevelopmentPlanning

User story

To Do Spec and dev review UX and Design Ready for Estimation

The aim is to get cards from the left, to the right. Friday, 26 October 12

DevelopmentPlanning

User story


It’s okay for cards to be sent back and forth between stages if they need further clarification

User story


DevelopmentPlanning

User story


Cards are ready when they fit the format for a product, are well understood and have clear

measurement criteria

User story


Simplicity Transparency

Flexibility

Main goals for dev process


Bugs


Roadmap

Delivering the work


Estimated

A user story

Current sprint In Progress Pull Request QA Complete

A second story

A user story

A second story

Prioritising estimated storiesFriday, 26 October 12

Estimated

A user story


A user story

A second story

A second story

Building a sprint, based on velocity


Estimated

A user story


A user story A second story

A second story

Picking up work from the current sprint backlog


Estimated

A user story



A second story

Code review from other developer in pull request


Estimated Current sprint In Progress Pull Request QA Complete


A second story

QA performed by product owner

A user story


Estimated Current sprint In Progress Pull Request QA Complete


A second story

Feature ready for release

A user story


Complete

Deployment

A user story

0.17.1

A user story

0.17.2

Bug fix

Completed features by this point should be in a state to be deployed to production.

Depending on the business need, they can be pushed directly to production (in the case of severe bugs etc), or as specific releases.

The aspiration here is to working, QA’d, and CR’d code automatically pushed to production, where features can be rolled out gradually, or switched on or off independently of code releases.

User story A another

story


Bugs


Roadmap

Measure


Bugs


Roadmap

Measure

Measuring the value of features

Development doesn’t end at deployment.

Not every feature needs accompanying metrics, but most should have them.

Did a feature have the expected result?

How can we tell?

Are we measuring the right data here?

How might we improve the feature?

How are we getting feedback?


Bugs


Roadmap

Measure

Measuring the value of features

Quantitive Qualitative

Kissmetrics (individual user interactions)

Google Analytics (larger trends, and heatmaps)

Ad-hoc API/DB Queries

In-app chat (eg. Olark)

Support software (desk.com)

User testing (recording how features are used in beta / testing)

Problem & solution interviews ( showing prototypes to users before building)


Amee product development workflow

Documents

Transcript of Amee product development workflow