IS480 Team wiki: 2012T2 Team Tenacity Project Management Methodology

From IS480
Jump to navigation Jump to search
Team Tenacity Logo 3.png
Home The Team Project Overview Project Management Project Documentation Learning Outcomes
Project Schedule Methodology Risk Bug & Testing Meetings Progress Reports

Methodology - Modified Scrum


What is scrum?

  1. An agile process that focuses on delivering the highest business value in the shortest time
  2. Rapid and repeated inspection of actual working software, typically every 2 weeks to 1 month
  3. Business sets the priorities while project team self-organizes to determine the best way to deliver the highest priority features
  4. Every 2 weeks to 1 month, anyone can see real working software and decide to release it as it is or continue to enhance it for another sprint

Characteristics of Scrum

  1. Self-organised team
  2. Product progresses in a series of month-long “sprints”
  3. Requirements are captured as items in a list of “product backlog”
  4. No specific engineering practices prescribed
  5. Uses generative rules to create an agile environment for delivering projects
  6. Individuals and interactions over Process and tools
  7. Working software over Comprehensive documentation
  8. Customer collaboration over Contract negotiation
  9. Responding to change over Following a plan


  1. Analogous to Extreme Programming iterations
  2. Typical duration is 2–4 weeks or a calendar month at most
  3. Product is designed, coded, and tested during the sprint
  4. Sprints are carefully planned to insulate them against changes
  5. Changes are generally pushed to dedicated sprints
Scrum Broken Down

Modifications made to standard Scrum Framework

  1. Have a Project Manager instead of having a scrum master
  2. Did not adopt all "scrum tools" e.g sprint burnt down chart
  3. Did not enforce "Daily Scrum"(daily updates of progress)
  4. We want to have flexibility in making changes during sprint development

For the most part, our team chooses to adopt SCRUM to the extend that it suits our team. We try not to over-burden the team by using unnecessary tools (e.g. sprint burnt down chart) and enforce "Daily Scrum". We feel that having a "product backlog" is sufficient in monitoring progress and instead of breathing down our developer's neck every single day to conduct daily scrum (and/or update sprint burnt down chart), we adopt useful practices like sprint review and sprint retrospective to manage our progress efficiently. In addition, we did not give a "Scrum Master" role to anyone but instead use a more traditional approach of having a Project Manager to oversee the progress of the team - reason being we feel that the role of a Project Manager is irreplaceable because of the amount of planning, scheduling, resource allocation; etc work that needs to be done. Moreover, being a 4-men team means that our Project Manager has to double up as a "Quality Assurance" manager who implements our testing methodology.

Modified Scrum Framework

Role and Role Description

Role Role Description
Product Owner - Our Client
  • Define the features of the product
  • Decide on release date and content
  • Be responsible for the profitability of the product (ROI)
  • Prioritize features according to market value
  • Adjust features and priority every iteration, as needed
  • Accept or reject work results
Project Manager
  • Represents management to the project
  • Removes impediments
  • Ensure that the team is fully functional and productive
  • Enable close cooperation across all roles and functions
  • Shield the team from external interference
The Team
  • Not totally cross-functional, but highly flexible
  • PM never changes
  • All members are full-time for primary roles

Ceremony and Ceremony Description

Ceremony Ceremony Description
Sprint Planning
  • Team selects items from the product backlog it can commit to completing
  • Sprint backlog is created
  • Tasks are identified and each is estimated (1-16 hours)
  • Collaborative effort, not done alone by the Project Manager
Sprint Review
  • Team presents what it accomplished during the sprint
  • Typically takes the form of a demo of new features or underlying architecture
  • Informal - 2-hour prep time rule
  • Whole team participates - Project Manager, Product Owner, and Team
Sprint Retrospective
  • Take a look at what is and is not working
  • Typically 15–30 minutes
  • Done after every sprint
  • Whole team participates - Project Manager, Product Owner, and Team

Artifact and Artifact Description

Artifact Artifact Description
Product Backlog
  • The requirements
  • A list of all desired work on the project
  • Ideally expressed such that each item has value to the users or customers of the product
  • Prioritized by the product owner
  • Re-prioritized at the start of each sprint

Sample Product Backlog

Product Backlog Sample


  1. Please visit this website: Mountain Goat Software for more information
  2. Alternatively, view Mountain Goat Software's slides here: Introduction to Scrum