This page last changed on Apr 03, 2009 by pwy4104.


Xerox uses Confluence Wiki to help organize their project related communications and information artifacts. They use Bob Swift's SQL plugin to embed external database information in wiki pages as well as generating data for charting on the wiki. Currently developers use a separate tool to manipulate the database tables and views. They would like the plugin to allow them to edit, insert, and delete database information through wiki pages. Xerox has asked us to develop an extension for the plugin which would provide them with the basic functionality to perform row operations on queries that are embedded in wiki pages. Time permitting the project might include multi-row operations, advanced data type support, and table scrolling. Another major feature, time permitting, is user-specific database sessions. Currently the plugin uses a single identity provided in a configuration file when performing database operations. The user-specific sessions would allow the plugin to connect the user's identity with the operations they perform. The extension to the plugin will be written in Java. It is intended to work with MySQL and Oracle 10g database servers. It must work in both Internet Explorer and Firefox browsers on Windows XP and Firefox on Solaris.

This project will take place over a 20 week development period in which incremental deliverables are expected by the customer. Utilizing a combination of XP and Scrum methodologies a maximum of 2 week sprints will be used to deliver each release. Frequent communication and stakeholder accessibility will be paramount in running successful sprints and allowing for quick response to project issues.

Roles and responsibilities within the team will be assigned and rotate throughout the duration of the project. For each sprint a Administrator, Tech Lead, Configuration Management Lead, and Test Lead will be chosen. There will also be a Scrum Master that will rotate every five weeks throughout the project. The responsibilities of the Scrum Master include running the daily scrum meetings (15 minute long meetings to communicate status and impediments), work with the product owners to further refine requirements and help remove any impediments the team has. The Scrum Master will also be accountable for updating story point burn-down charts and tracking metrics throughout the sprint as well as updating the team time sheets. Since we will be using test-driven development, team members will be responsible for writing tests but a team member will be chosen to oversee testing efforts and to ensure that quality tests are been written. The test lead will use the selected metrics below to track and monitor testing coverage and pass/fail rates. The configuration management lead will be chosen for each sprint and will be tasked with maintaining the VM environment, ensuring CVS is properly configured and used, as well as maintaining the project wiki. The tech lead will also be chosen for each sprint and will be responsible for addressing technical issues, enforcing XP engineering practices and documenting design/implementation work through the sprint on the team wiki.

The senior project team will be responsible for choosing which user stories will be implemented in each sprint based on priority (determined by the Product Owner), as well as story size and velocity (determined by the team). Team Wirox will also be required to track progress as well as keep time cards of weekly tasks and achievements.

Goals and scope

The primary goal of this project is to produce a SQL plugin that will both satisfy the needs of Xerox and have the opportunity to be merged into Bob Swift's existing SQL plugin. This will be the first project in which Team Wirox will be required to exercise the full development lifecycle and it is a goal to gain knowledge of both the software lifecycle and the related practices in the XP/Scrum methodologies. It is also important to enhance the Xerox/RIT relationship through a successful senior project.

The scope of this project includes the extension of the existing SQL Plugin by Bob Swift to enable the manipulation of database information. This consists of inserting, updating and deleting from the databases that are accessed through the Confluence Wiki. The datatypes that will be supported will be: varchar2, number, integer, decimal, float, precision, dates and possibly timestamps. Single row transactions are required but with desirable functionality for multiple row transactions. The plugin will be required to distinguish between users that may edit or simply view database information.

Team Wirox will not be responsible for handling existing bugs in the current SQL Plugin for Confluence Wiki. Datatypes other than those mentioned above will not be explicitly supported.

no currency.


  1. Project website holding all non-proprietary work products and project artifacts maintained in the project account on the web server. If for some reason, you are hosting project artifacts on another web server, a static mirror image must also be maintained on the department server. Project artifacts will be pulled from the team Confluence wiki space and uploaded to the RIT SE Department web server ( using the "space export" functionality of Confluence.
  2. Project plan, schedule and process methodology definition prepared by the end of week 3 of the first term.
  3. Tracking report for time/effort worked by each team member and the team aggregate updated on the project website weekly. Tracking report for at least two product/process metrics appropriate to the project and development methodology updated on the project website at least every two weeks.
  4. Interim status and final project presentations
  5. Project poster and presentation at "SE Senior Project Day"
  6. Project technical report
  7. Interim and final team self-assessment
  8. Post-mortem curriculum reflection report
  9. A CD(s) at the conclusion of the project containing all project artifacts.
  10. Each team member completes a Software Engineering Program Senior survey
    Milestone Estimated Completion Date
    Team name chosen End of Week 1-1
    Project Synopsis End of Week 1-1
    Project synopsis approved End of Week 1-2
    Team Website Started including team information and approved synopsis, first tracking report End of Week 1-2
    Project information survey completed End of Week 1-2
    First draft of project plan End of Week 1-3
    Development methodology chosen and documented on project website End of Week 1-3
    Product/process metrics chosen and documented on project website End of Week 1-3
    Mid-term Peer evaluations completed End of Week 1-5
    Draft of interim presentation completed End of Week 1-8
    Interim presentation completed End of Week 1-9
    Individual end-of-term peer evaluations completed End of Week 1-10
    Interim team self-assessment completed End of Week 1-10
    Project website contains all project artifacts End of Week 1-10
    Course evaluations completed End of Week 1-10
    Accreditation evaluations completed End of Week 1-10
    Technical report completed End of Week 1-11
    Summary of reflection meeting completed End of Week 1-11
    Project Plan updated for second term End of Week 2-1
    Completed session on making poster and writing technical report End of Week 2-4
    Mid-term peer evaluation completed End of Week 2-5
    Project poster concept completed End of Week 2-5
    Preliminary project poster completed End of Week 2-6
    Project Poster Completed End of Week 2-7
    Draft of final presentation Completed End of Week 2-8
    Technical Report published on team website End of Week 2-8
    Draft technical report completed End of Week 2-10
    Individual peer evaluations completed End of Week 2-10
    Team final self-assessment completed End of Week 2-10
    Post-Mortem Curriculum Reflection completed End of Week 2-10
    Project website up-to-date with all project artifacts End of Week 2-10
    Course evaluations completed End of Week 2-10
    Accreditation evaluations completed End of Week 2-10
    Final project artifacts completed End of Week 2-11
    Final technical report completed End of Week 2-11
    Summary of curriculum reflection completed End of Week 2-11
    Senior survey completed End of Week 2-11

Risk Management

Wirox will be using a risk register to track and manage risk events throughout our project. Risk events refer to specific, uncertain events that may occur to the detriment (or enhancement) of the project. A risk register (provided below) will be used to document potential risk events and related information. The name and description of the risk are listed in the table in addition to the root cause of the risk, triggers for the risk (indicators or symptoms of actual risk events), potential responses to each risk, and the person who will own or take responsibility for the risk. The probability of the risk occurring and the impact (in hours) of the risk event are also listed and used to prioritize the risk events (adapted from Information Technology Project Management, Fifth Edition by Kathy Schwalbe).

ID Rank Risk Description Category Root Cause Triggers Potential Responses Owner Probability Impact (hours) Total
Status & Actions Taken to Reduce Likelihood
Testing Environment Testing tasks/use cases are impeded.
Environment Cannot feasibly test task/story or cannot develop adequate test case with available tools. 
  • User story is impeded for at most a day
  • See advice of other team members
  • Consult with sponsor/product owner
Test Lead
16 Investigating confluence integration test  framework (active)
Role Mapping Confluence users cannot be mapped to SQL users.
Session Related Issues SQL users cannot be mapped to Confluence users or are unknown.  Cannot connect to databases using users information acquired through Confluence
  • Discuss alternatives with Product Owner(s)
  • Is it required?

12.75 - depends on if feature will be implemented
Database Support Issues
Stories/tasks related to certain row operations could be impeded.
SQL Specific Issues
  • Implementations of SQL that do not conform to standards
  • Advanced vendor specific feature
Database test cases fail
  • Evaluate trade-offs
  • Discuss necessity of specific vendor support with Product Owner(s)

11.4 - spiking potential issues
12 4
Technical Design Issues
Unsure how to manage server side results for future editing
Plugin development
Inexperience or lack of domain knowledge, complex problems 
Severe early impediment to database editing related tasks
  • Speak with sponsor
  • Consult with faculty advisor
  • Readjust sprint priorities
Javascript/JQuery development stories/tasks are impeded. AJAX Lack of skills/knowledge/experience with Javascript/JQuery
  • Lack of progress for user story/task
  • Seek advice of team members
  • Re-evaluate use of Javascript for task/story with Product Owner(s)
2 6
Confluence Wiki Team is unable to complete user stories due to technical challenges with Confluence Plugin architecture/ APIs.
Plugin Development Development team has no previous experience working with Confluence Wiki. User story/task is marked as having a confluence API related impediment for more than 3 days
  • Move story to back-burner
  • Move to future sprint
  • Discuss user story with Product Owner(s)
8 7
Communication Possible miscommunications between the development team and stakeholders. Stakeholders Geographical separation, misunderstanding of subject matter/domain/technologies
At iteration planning meetings, review meetings, there are unmet expectations.
  • Compromise with product owner
  • Add stories to address unmet needs
  • Change communication methods
10 8
Integration Since the project must integrate properly with the already existing SQL plugin, design/implementation choices. Open Source Community
SQL plugin design
Design/implementation of features impeded by existing SQL plugin design.
  • Investigate work-a-rounds
  • Communicate with Bob Swift
  • Develop plug-in as a standalone
  • Adapt existing plug-in to ours (re-direct old-style requests?)
Scrum Master/ Product Owner
Flow of Events User stories related to AJAX/client-server interactions may not be completed or are impeded.
Plugin Development Lack of knowledge on how Confluence handles requests. TBD / Unknown?
  • Re-prioritize story
  • Consult with product owner(s)
  • Do more technology prototyping/spiking/research
- after initial technology spike team is more comfortable with plugin flow of events
Virtual Machine Virtual Machine is unavailable for development.
  • Crash
  • Bad configuration
VM is unavailable for 10 minutes.
  • Work with Kurt to resolve issue
  • Designate a team member's computer as the temporary test environment if necessary
Configuration Lead
10 Poor estimation Estimations are too low and leads to readjusting priorities and sprint backlog.
Scrum methodology
Inexperience Consistently high estimation error %, sprint goals not being met
  • Planning resolution meeting
  • Try new estimation techniques
Sprint scrum master .2 2 (does not include non-quantifiable impacts)
.4 Estimation errors and scrum teams progress towards sprint goal will be tracked by Scrum Master throughout sprints
Interoperability with other Confluence Wiki plugins. Plugin Development Plugin cannot be used as a compatible macro for charting plugin (or other).
Charting fails to work when using the SQL macro.
  • Check test cases for failure
  • Fix code for outputting to wiki markup
11 12
Plugin Ownership SQL Plugin owner(s) may not accept our work and integrate it with their plug-in
Bob Swift SQL Plugin owners are not responsive to e-mails, provide negative feedback regarding project.
Unknown (may happen after project is completed)
  • Release plugin separately
  • Xerox takes ownership of plugin
Scrum master
0? No impact on schedule, but would impact overall project success.
  Scrum master will contact Bob Swift (see other risk too).
1 6
Cannot build project (Maven) The project cannot be built using Maven.  Plugin Development Development team has no previous experience working with Maven. Cannot build due to configuration problems
  • consult expert


The project will be tracked using our team's wiki as a communication tool. Specifically using story point burn down charts which will track story points completed over time and hours burn up chart which tracks time spent. Charting will be done using the wiki's built in charting macro.

Project work will be divided into sprints. Each sprint will last 2 weeks.The goals for each sprint will be determined collaboratively with the product owners at the start of each sprint during a sprint planning meeting, taking into account the metrics generated in the previous sprint. These meetings will be done either in person or through use of teleconferencing technology. Planning will take into account what features have been implemented in previous releases, any additional features and feedback from the Product Owner based on the overall progress. The outcome of planning meetings is a sprint backlog based on team estimates for highest priority items. We will hold sprint review meetings to give demonstrations of progress to the Product Owner at the end of each sprint.

The following sections give the currently known work breakdown and status of user stories.

Work Breakdown Structure and Gantt Chart

ID Name Duration Start Finish Predecessors Notes
1 Last Day Before Break .d 12/19/08 12/19/08

2 Holiday Break 12.d 12/22/08 01/02/09

3 Sprint 0 (Weeks 4 & 5) 12.d 01/05/09 01/13/09 2
4 Sprint 1 Planning 1.d 01/15/09 01/15/09

5 Sprint 1 (Weeks 6 & 7) 12.d 01/15/09 01/27/09

6 Sprint 2 (Weeks 8 & 9) 12.d 01/29/09 02/10/09 5
7 Draft of interim presentation completed .d 02/06/09 02/06/09

8 Interim presentation completed .d 02/13/09 02/13/09

9 Sprint 3 (Weeks 10 & 11) 12.d 02/12/09 02/24/09 8
10 Last Day of Winter Quarter .d 02/20/09 02/20/09

11 Technical report completed .d 02/27/09 02/27/09

12 Winter/Spring Break 5.d 03/02/09 03/06/09 9
13 First Day Spring Quarter .d 03/09/09 03/09/09

14 Sprint 4 (Weeks 1 & 2) 12.d 03/12/09 03/24/09

15 Sprint 5 (Weeks 3 & 4) 12.d 03/26/09 04/07/09 14
16 Sprint 6 (Weeks 5 & 6) 12.d 04/09/09 04/21/09 15
17 Sprint 7 (Weeks 7 & 8) 12.d 04/23/09 05/05/09

18 Sprint 8 (Weeks 9 & 10) 12.d 05/07/09 05/19/09 17
19 Sprint 9 (Week 11) 5.d 05/21/09 05/26/09 18
20 Last Day Spring Quarter .d 05/15/09 05/15/09

  Name Size Creator (Last Modifier) Creation Date Last Mod Date Comment  
File project-schedule.mpp 240 kb Paul Yates (modified by Paul Yates) Jan 08, 2009 Jan 08, 2009 current schedule Edit | Remove
PDF File project-schedule.pdf 258 kb Christopher Daniels (modified by Paul Yates) Dec 16, 2008 Jan 08, 2009 Needs update for sprint date changes Edit | Remove
File Project-Schedule-Update.mpp 152 kb Paul Yates Jan 08, 2009 Jan 08, 2009 Updated project schedule post-break Edit | Remove

Estimation Techniques

We will be using XP/Scrum agile estimation techniques based on "Agile Estimating and Planning" by Mike Cohn which are outlined below.

Velocity-Driven Sprint Planning

Adjust Priorities

The features implemented for each sprint will be pulled from the product backlog, a list of user stories/features prioritized by the product owner.  Sprint review meetings will be held at the end of each sprint.  During these reviews, new functionality and capabilities that were added during the sprint are demonstrated to stakeholders and feedback is received.  The product backlog will be reviewed and priorities adjusted if necessary.

Determine Target Velocity

When possible, historical values for the target velocity will be used.  For example, the target velocity for the next sprint will be set to the average velocity of the previous sprint.  In the case that there are significant technology changes, the historical velocity value will be used along with a observed velocities in technology spikes and a velocity forecast.  Velocity forecasts will be determined by:

  1. Estimating the number of hours each person will be available to work on the project each day.
  2. Determining the total number of hours that will be spent on the project during the release.
  3. Arbitrarily/randomly selecting stories, expanding them into tasks, until enough tasks to fill the release have been identified.
  4. Converting the velocity determined in the preceding step into a range (multiply by 60% and 160%). 

Identify Sprint Goal

A goal will be determined that succinctly describes what we would like to accomplish as a team during the sprint.  For example "All X features are finished" or "make progress on X".  The sprint goal will be a unifying statement about what will be accomplished during the iteration and does not have to be very specific. 

Select User Stories

Wirox will then meet with the product owner(s) to select stories that combine to meet the sprint goal.  This selection process will be driven by the priority of each story.  For example, a user story related to the goal that has a very low priority may not be included in the iteration.  The selected stories will be marked for the sprint on the product backlog page. 

Split Stories Into Tasks

Next, Team Wirox will decompose each user story into the tasks necessary to deliver the new functionality for that story.  This will include:

  • Writing acceptance test cases
  • Any analysis tasks
  • Documentation tasks
  • Spikes if necessary (a task included in an iteration plan that is being undertaken specifically to gain knowledge or answer a question)
  • Design tasks if necessary infrastructure is not in place
  • Any supporting tasks not related to coding (environment maintenance, configuration changes, etc.)

Estimate Tasks

Task estimates will be expressed in terms of ideal time.  Tasks should be created with an approximate size so that each developer is able to finish an average of one per day.  Large tasks greater than a day will be refined into smaller ones.  Planning poker and Wide Band Delphi techniques will be used to estimate the size of user stories.

Measurements & Metrics

At the planning meeting for each release the team will discuss which metrics are most appropriate to capture for the up-coming work. In addition to the time-tracking sheets that are maintained for Senior Project, there are several other measurements that will be chosen from. The primary use of the measurements are to aid in averting risk to help determine progress through a release.

Velocity - This is a measurement of how fast work is been completed. It is determined by the story points of completed user stories divided by the length of each sprint. This will be used during the planning stages of future sprints to determine the which and how many user stories will be targeted for the next release.

LOC - Overall Lines of Code (LOC) will be compiled for the project before and after each user story. This will be used to aid in estimations for future user story size and track the growth of the project.

User Story Status/Impediments - We will record user stories and their associated status and current impediments in a table. This will be used in order to keep track of associated risks, track progress, track overall impediments and associate task ownership for a given user story.

Test Pass/Fail - Test related information will be recorded in order to track project health. In our methodology, having and passing tests is how user story completion is determined. Code coverage information will be generated by running unit tests.

Time/Activity Tracking - Time/Activity tracking will be used to determine day to day activities and sprint process. Besides being part of the RIT senior project requirements this measurement will contribute to the daily burn-up chart (described below).

Burn-up Chart - This chart will map total spent time relative to the total estimated time for a sprint. This chart will be updated daily. This measurement can help make sure estimates are on track and validate estimations for a sprint.

Burn-down Chart - This chart will map remaining story points to be implemented in the sprint against the estimated total. This will give a visualization for how much remains to be completed for the sprint as well as determine if goals are still on target. It will be updated at daily scrum meetings by the scrum master.

Technical Process

The team will adopt a combination of XP and Scrum methodologies that will make up the technical process that will be used. For development activities the team will use most XP practices for planning, designing, coding and testing. The practice of no overtime, constant customer availability and starting each day with stand up meetings are not applicable to the senior project as a result of other obligations and restrictions. Scrum practices that will be adopted will consist of the use of a product backlog for release planning and progress tracking and in conjunction XP stand up meetings will be used to communicate individuals project activities and any impediments. Timothy Luksha will be the primary product owner (Peter Alfvin may also fill this role) and will be used throughout for requirements elicitation and user story prioritization.

Nice job, you guys.  I only have a few comments.

The ScrumMaster role is often misinterpreted as an essentially administrative role.  As the name implies, the ScrumMaster is supposed to be a master of Scrum and someone who ensures that Scrum is being appropriately followed within the team.  In this context, a consultant and author whose opinion I really respect has made several related suggestions that I'm passing on to you for your consideration:
* Rotate/share administrative responsibilities (e.g. updating team tracking artifacts) through some mechanism other than asking the ScrumMaster to perform them.  This builds appreciation for and drives improvement in the administrative activities, promotes the true ScrumMaster role and promotes team self-organization by keeping the team from being reliant on the ScrumMaster
* Do not rotate the ScrumMaster role frequently or give role to someone who doesn't want to do it.  Becoming an effective ScrumMaster takes many months and rotating frequently pretty much guarantees ongoing incompetence in this role.  I realize that one of the goals of the project is to give everyone experience in the various roles, but you can at least use longer "terms of service" and, unless it's a hard and fast requirement to give everyone a shot at this role, you might want to use more of a "pull" approach to taking this role on, as you would with iteration tasks.

With respect to sprint goals and committing to the sprint, it wasn't clear from the wording how you viewed the team interacting with the product owner.  I think two things are important:
* Establishing the sprint goal should be a collaborative activity between the team and the product owner
* The backlog items for the sprint are not committed to until the team has completed their task planning

Posted by at Dec 21, 2008 10:17

The ScrumMaster should also feel empowered to let us know if we aren't doing a good job as product owners/customers and what changes the team needs from us.

Posted by tluksha at Jan 05, 2009 09:29
Document generated by Confluence on May 21, 2009 10:23