IS480 Team wiki: 2014T1 Team Epsilon Project Management

From IS480
Revision as of 20:16, 24 December 2014 by Lavinia.tay.2011 (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Team Epsilon Logo.png.png

Home   Project Overview   Project Management   Documentation   Team

Methodology   Project Schedule   Metrics Management   Risk Management

Agile Software Development

Choice of Methodology

Our team will be adopting the Agile software development methodology in managing this project.

We aim to:

  • Deliver working software more frequently
  • Prioritize functions based on business value
  • Measure progress principally based on working useful software

Primary Essence of Agile

To focus on delivering value-adding functionality as often as possible, from the point of view of our customer.


Many tasks we perform, while necessary in most cases, do not provide actual value to the customer by themselves. In software development, it means that although some tasks like “analysis”, “coding” and “testing” are necessary to achieve and deliver our end-product or feature, they are not what our customer seek. The value then, is in the “working feature” that our customer needs.


To measure and deliver value to our customer, we adopt the classic “stories” that agile methodology provides. It is assumed that all tasks that need to transpire to deliver a story will ensue. But we should not be giving or getting any cookies for simply completing these menial tasks. Rather, we aim to only get cookies when we deliver working (running & tested) features that the customer wants; we get cookies for delivering value.

Tell a Smaller Story

Our system also has its share of “Epic Stories”; stories that in our group’s context, have 150 story points and above. This simply means the story is more complex and bigger, resulting in more effort and time needed to complete it. In order to deliver value as often as possible, we strive to break the story (feature) up into smaller pieces whenever possible; the smaller a story, the faster we are able to deliver value. Smaller stories also mean the estimation of effort needed is more accurate, it is easier to design and improve as we go along, and it is easier to test and deliver working features. Alas, no matter how small we split a story, we do not split by tasks - each split in and of itself must still provide demonstrable value to the customer.

Burn Stories; Not Tasks

Traditional agile burn down charts tracks by the task-level. We want to focus on completing stories, not tasks. Besides focusing us on the wrong things, it also burdens us to worry about too many things by encouraging us to micro-manage menial tasks. This is very “un-agile”-like and will only lead to reduced productivity and diminished value for the team.

Burn Up; Not Down

Our team will be using a burn up chart instead of a burn down chart to track our progress. Although both charts are able to track how fast the team is progressing, the difference between them is that while a burn down chart tracks how much work remains to be done in the project, a burn up chart tracks how much work has been completed and the total amount of work done by the team.

Scope creep and additional requirements added later after the inception of the project development are often the bane of software projects. In the face of scope creep, burn down charts might start to look like little progress is being made. With a burn up chart, it improves the visibility of the project progress and shows clearly the problem of scope creep (if any).

Although we have already signed a requirement document with our sponsor, in the real world, there is often no 100% lockdown of scope even after signing off of the requirements. Besides, we are relatively inexperienced in handling projects and we do not know how much we are able to complete within a given timeframe. Our supervisor's advice was to not impose an artificial limitation on the project scope, and we agree that we should be learning, and adjusting our schedule as we go along. This will also allow us to embrace (important and crucial) changes that happens along the way (e.g. feedback given by users that will heavily impact the usability of our system).


In order to ensure all parties get updated regularly about the project's progress, our team will be using:

  • Daily Conversation: Face-to-face meet-ups, Whatsapp, or Facebook messaging to keep the team up to date. This will replace our group's daily standup meeting as it provides us more flexibility.
  • Weekly Round-Up Meeting: Every week, we will have an internal meeting where we summarize and consolidate what has been done over the past week, as well as what is ahead of us.
  • Fortnightly Sponsor Meeting: Once every two weeks, we try to arrange a sponsor meeting to update our client with our team's progress as well as deliver him a workable piece of software.
  • Supervisor Meeting: Once every three to four weeks, or by need basis, we will arrange a supervisor meeting to update our supervisor regarding the team's progress as well as clarify and consult him on any doubts we might have regarding the team's direction and project.