Using Trello to manage adaptive plan

Trello Links to an external site. is a tool we'll be using to manage our client project plans.  We have shared a Trello board with each team that your professors can already access, and you should be using this to manage the Inception phase of your project.  You will create an additional plan after Inception to manage your client project sprints. This will allow your team, your client, and professors to access and monitor your plan throughout the project. 

Trello is a "task board" system which uses digital cards to represent either a user story or individual task.  Trello also uses columns (called lists) to collect cards based on some criteria. Lists are commonly used to signify the state of a particular card.  We'll be using a standard known as KANBAN in this class to manage user stories in a particular sprint, which assumes there are four standard lists (or states) of "Not Started", "In progress/development", "In test/review", and "Signed off/Deployed".  The KANBAN method also adds a constraint that only a certain number of cards should be allowed to exist "in progress" or "in review" (e.g. max of 4).  This forces the team to clear up bottlenecks before they happen and work together to push cards forward before taking on new work. [NOTE: Trello itself does not enforce this constraint - your team will have to monitor the number of cards in each column to adhere to this rule.]

To help you use your Trello board more effectively, please follow the structure outlined below. Your Trello board to manage your sprints should contain the following lists: 

  • User Stories - this list should contain one high-level card per user story. As you begin to work on a user story, you will "explode" this user story into the specific functional requirements to be performed to implement your user story (no card limit)
  • Not Started - this list should contain the specific functional requirements or features for the user story (or user stories) to be completed in a particular sprint. Cards in this list have not been started, and are not limited in number.
  • In Progress/Development - this list should contain specific functional requirements or features that are currently being worked on by team members (limit of 4 cards in this list at a time)
  • In Test/Review - this list should contain completed functional requirements or features that are being reviewed/tested by the client/team (limit of 4 cards in this list at a time)
  • (Optional*) Bugs Logged - this list should contain all bugs found during development/testing to ensure they will be fixed. Make it clear which user story is affected by which bug(s) (no card limit)
  • (Optional*) Bugs Fixed - as bugs that have been found are fixed, they should move to this list (no card limit)
  • Signed Off/Deployed - once a user story has been signed off/deployed, move the single user story card to this list (no card limit)

* If you choose not to add separate lists to manage bugs, you will need to add another checklist to each card to keep track of bugs. Use the comments section to add details about the bug. When a bug is found, move the card back to "In Progress/Development" until it is fixed. If a bug affects multiple user stories, add it to each affected card, and move those cards back to "In Progress/Development".

Details of cards representing functional requirements in Trello

When working on a particular user story in a given sprint, you should "explode" each high-level user story in to many cards. Each of these cards should represent a single functional requirement or feature that you have identified. While this level of detail is often sufficient for professional developers to perform their tasks, in our class you should create a checklist within the card to identify the Analysis, Design, and Construct tasks (ADC) for that feature to help better manage your efforts (refer to the Project Planning lecture for ideas of tasks to be performed during ADC). As you complete the ADC tasks and move the feature from "In Progress" to "In Test/Review", this move implies that you are performing testing tasks for the feature. After you finish testing and move the card from "In Test/Review" to "Signed Off/Deployed", this implies that you are completing deploy tasks for the feature.

In addition to adding ADC tasks to a given card, we also expect you to include the following information for each functional requirement or feature:

  • Add members responsible for the card
  • Add a due date to the card
  • (Optional, but helpful) Color-code each card related to a single story to be able to distinguish which card belongs to which user story (especially useful when working on multiple user stories in a sprint)
  • (Optional) Adding tasks for test and deploy to help better manage your work, and eases your ability to calculate percentage of work complete

Please refer to the Latinitas Trello Board example Links to an external site. to illustrate the above ideas. The exploded user story is tied to the functional requirements for the donation report user story outlined in the Project Planning lecture. Many of the tasks identified for these functional requirements are included in the example Gantt chart from this lecture. Additional user stories listed are those identified in the Agile day class exercise. This example hopefully illustrates how all of the pieces can come together in a Trello board to better manage your project.

While we have specified a structure we would like you to use with the Trello board for our class, there are many additional features in Trello that you can use to help manage your software development (e.g. assigning a card to specific team member(s); adding deadlines to cards; using stickers to visually flag specific cards; adding comments to a card).

The purpose of using Trello is to allow all team members, including your professor and client, to access the development plan at all times. Trello has an app that you can add to your smartphone and download to your computer, which makes it extremely easy for all team members to update immediately, and check in at any time to see the (hopefully) realtime status of your project.