Repository navigation
Using Trello For Project Requirements, Design and Estimate
We use Trello to help us run a project
You can use Trello boards, to get you to an MVP estimate which fits your budget
We use the following Trello Boards:
- Project Overview
- Discussions
- UserStories
- Features
- Investigations
- Implementations
- Design
- Tasks
Depending on the complexity of the project, each board can be the parent to a number of child boards. There are no hard and fast rules about how the boards are used. It's up to you as a team to work out what suits.
...however, here's a guide!:
We have set up an example organisation for you to use as a template.
The organisation is called The Urban Wild. The organisation wants to enlist the help of members of the public to log wildlife in their local area.
It has set up a project to produce an app to do this. The project is called Wild Logging.
We have taken the project right through the requirements capture process, to give us a useful design and a set of tasks to produce that design.
Use this board as the 'Front Door' to your project. Use it to tell people where to find important resources; the brief, people, repos and other boards in the project.
Beware privacy!
Used as an informal board where people discuss ideas without cluttering up other boards. Ideas can be linked to later.
Used to define avatars who mirror real-life users actually use your future product.
Use one card to describe one process a character or characters will use.
Use it to shake out good ideas, UI, interactions etc.
IMAGINE the product being used, and the parts which interact with the characters.
Use these boards with the brief and your user stories to describe the features of the MVP which your users interact with.
Layer your description to include the business layer.
Be careful of the boundaries of your description. You are describing a UI (if required) and business objects and processes. Stop as soon as you hit a technology boundary.
If your product is an app, for example, describe the UI which your characters will use as they perform their actions.
For example:
CasualUseApplication - a mobile web application to create observations of wild life.
Contains:
-
CasualUse:Homescreen- the main screen
Contains:
CasualUse:WildInputBoxCasualUse:LogItButton
CasualUse:WildInputBox - holds the name a of a species. When the user types, invokes the WildLifeSuggestionProcess, which contacts the CasualUseAPI and returns a set of Living Things.
This describes some UI, the way it interacts, some of the data model and some sort of online service.
It's not describing ANY form of implementation.
The features board is largely abstract. It has no idea of the technologies which are going to be used to fulfil the user stories. This is where the Implementations board comes in. Drill down through the features, from the top-level to the bottom. For each new feature having an ambiguous implementation, you need to define one.
For example: The brief has described a web-page which a casual user can use.
There is no further definition, so it's up to us. We want to use GitHubPages for this. So we flag an investigation to find out if it's suitable.
The Investigations board is a list of investigations to be done to ensure that the team has enough understanding of the technologies it will use, to be able to make an estimate. When an investigation goes into the board, it goes into 'To Do'. Someone needs to be assigned to it. That's the job of the TechLead. When assigned, the team member puts the investigation into 'Pending'. When they have completed it, it goes into 'Done'. Investigations need a conclusion, and ideally some code, supporting it.
This board simply contains statements about the technologies which are to be used to fulfil the features. Each statement must be backed by an investigation or a requirement of the brief.
The design board is a description of the actual components which will be constructed to fulfil the features. It is up to the TechLead to ensure that each feature is fulfilled by the design, and to check-off the features in some way. We use labels on the features board to flag when a feature has a design fulfilment, and we link to the component responsible.
Components are heavily coupled to the implementation choices which have been made. It not intended to have a a one-to-one mapping from features to components, simply components which fulfil features.
The Tasks board is where things really come together. When the the design is complete, the Tech Lead and Project Manager need to get together to create the tasks which build its components. A Task describes work done to build a component, or part of a component, by a SINGLE person. It has an estimate in hours. Try to make sure a task is at least an hour and preferably more than 2, or you will have a crazy number of them!
We use Scrum For Trello to help us.
We define a set of lists in the Tasks Board. Each represents a Sprint. We use the budget to help us work out how many sprints we can work. A sprint lasts 2 weeks, and finishes with a deliverable.
We order the tasks into sprints: tasks for foundation components go in first, followed by those to build their dependents.
Again, it's up to the TechLead to audit the design, to make sure that each component is fulfilled by a set of tasks.
Scrum For Trello will add up all the estimates for you, to a total. Compare this with your budget!
We searched around for ages for something to help us schedule tasks, and none of the apps we looked at helped in the way we wanted them to, which is to help when we need them, and get the hell out of the way when we don't. So we didn't use them.
Then we found Ganttify which takes data from your Trello cards and builds a Gantt chart out of them, live, as though it was part of Trello. Article here. Try it; you won't be disappointed.