A quick summary about how to use Kanboard
What is Kanboard?
Kanboard is a free/open source/self-hosted Kanban project management, designed for teams operating under an agile software development framework for organizing tasks. UAS@UCLA uses this interface for evenly distributing tasks to all of its active members and tracking the progress of these tasks throughout each two-week sprint cycle.
Why do we need this?
Like many organizations at UCLA, this club has experienced a series of member dropouts due to poor task distribution and, on the flip side, member burnout of the key players behind our various subsystems. These issues only become worse as exams/research/other activities come into play, which only added fuel to the fire. To remedy this, Kanboard was implemented to keep track of every task occurring on the team, with every active issue assigned to a person and given a point value corresponding to how long the issue is expected to take for the assigned person to do.
How can I sign up?
Go to the UAS@UCLA Kanboard
Click "OAuth2 Login", and authenticate using Slack
- There is no need to sign up by request to the UAS@UCLA email since Kanboard will automatically create a new account for new members signing in through Slack
Contact someone on the UAS@UCLA board to gain permission to view the interval sprint cycle projects
- Alternatively, send an email to UAS@UCLA
Layout and Functions
Sprint project layout
- Sprints are two weeks in duration
- Sprints begin with a given set of tasks. This set of tasks should only decrease throughout the course of a sprint (no new tasks should be added until the next sprint without leadership approval)
- Each task is assigned points of powers of 2 (1, 2, 4, 8) (to accurately distinguish between each level). Work is spread across two weeks, so one 8-point task would mean an hour of work for two weeks (with a couple off-days)
- 1 = an hour or two of work
- 2 = 3 - 5 hours of work
- 4 = 6 - 10 hours of work
- 8 = a full day of work, plus some
- All active members receive between 6 - 10 points for each sprint cycle
- Tasks are ordered into columns as follows:
- TODO = tasks in the current sprint that have yet to be started
- In Progress = tasks that are currently being worked on
- Testing / QA = tasks awaiting approval from a leader for meeting its spec, or a task that needs to be tested in simulation/on hardware
- DONE = tasks that have been completed in the current sprint (i.e. passed the testing phase as well)
- Backlog = tasks for future sprints
- There should only be one project for all tasks for a current sprint. Filters should be used to narrow down all of the items for a sprint into a more manageable subset.
This isn't required knowledge, but it is interesting to know what is happening behind the scenes when UAS@UCLA leaders are assigning tasks to everyone.
Sprint cycles should allow leaders to track the velocity of the team, in terms of points/day that the team is getting through. This is tracked using a burndown chart
In addition, point balancing across members should reduce burnout of veteran members and leave newer members with a constantly-refreshing pool of tasks to work on and develop their skills. Task distribution is tracked through the user repartition chart