Scrum Management System is a web-based software system which is designed to help software developers who are using the scrum development process, to manage their software requirements and project activities. The project was proposed by Intel as a replacement for the management system that they are currently using. The current system is not a web-based solution and has some usability issues which the sponsor requested be upgraded in the new system. Since a system is already in existence, the sponsor also provided the team with a current database structure which was used for the new system to ease the transition between systems. In addition, no data migrations were required by the sponsor.
The main goal of the project team was to realize the functional requirements and set up a base system which Intel could continue development on. Due to this, no administrative operations were required to be included in the system. All of the technology choices were left up to the project team.
The basic requirements for the system were already well planned by the project sponsor since the proposed system was an upgrade to an already existing system. This meant that the project team’s primary responsibility was to understand and clarify the requirements as well as propose some upgrades to the current system.
The two largest requirement areas which the sponsor was requesting were the drag and drop functionality as well as the windowing functionality. Drag and drop was implemented for both table rows as well as individual elements within the Document Object Model (DOM). The windowing functionality which was requested was maximize, minimize, pin, restore, and close. Each of these functions was implemented on each window section within the main browser window.
Following is a list of the project requirements which were completed for the project. These are taken from the project backlog which was the process document used to manage development tasks.
Create initial view for the hierarchy of Product/Project/backlog/sprint
Connect the database to the explorer view to enable the selection of products from the view
Connect the database to the explorer view to enable the selection of projects from the view
Connect the database to the explorer view to enable the selection of sprints from the view
Make storylist same height as explorer window when application loads.
Implement loading status display during loading.
Rearrange edit task window to go horizontal.
Setup intial size of edit task window.
Implement popup of user story window when add new story button has been pressed.
Restrict size of move sprint in storylist
Implement age instead of modified date in storylist
Restrict size of age field in storylist
Implement scrollbar for overflow in storylist and storyboard.
The main constraint for our project was on the database structure. Since the customer is currently using their system they already have a lot of data in a database. In order to ease the transition of moving that data between the systems, we developed the structure based on a diagram which the sponsor provided.
Our project sponsor requested that we use the Scrum development process in order to gain some experience and knowledge in the problem domain for our product. This also allowed us to increase the usefulness of the software by solving some of the process problems which we were running into throughout development. None of the team members had any experience using this development process so research was conducted on the subject to help mitigate the risk that the process would not be followed correctly. After some research a project schedule was developed which consisted of several sprints of varying lengths to address the changing needs of the project/product.
There are several areas where the project team learned critical lessons about the development process implemented. First and foremost, the most difficult issue which had to be overcome is the amount of scheduling which is required for the scrum process to be completed. Since frequent meetings are used to track progress and ensure that everything is getting completed, if team members have differing schedules it becomes more difficult to arrange regular meetings. This was a major problem for our group because the college environment is not as regulated as that of a general work day and individual group members had other commitments which made the task of scheduling difficult. The second major lesson we learned was that the scrum process was not designed to be implemented until after the initial design and documentation set-up has been completed. This is because the process centers on task progress and completion, where as much of the initial work on a project leads up to the creation of the project tasks.
Each of the team members was assigned at least one role to ensure that tasks were completed correctly and on time. The project team agreed from the start that these roles were not connected with any particular project tasks but simply responsibilities which each individual was in charge of making sure got completed.
As stated in the previous section, the project schedule was broken down into a series of sprints which varied in length between two and three weeks. The first sprints were three weeks in length because they consisted mainly of planning and initial development tasks. As the project progressed we made the sprints shorter to increase the amount of feedback we received from our sponsor and better handle changing priorities as the amount of time we had remaining to finish up our tasks was running short. This ensured that those items which contained the most business value to the customer were completed within the project schedule. The full project schedule along with dates is listed below for reference.
The major part of the system design was decided up front by the technology choices that the team made. The major decision which needed to be made was to whether to go with an ASP.net product or a Ruby on Rails product. The team decided on Ruby on Rails which meant that a lot of the design was set up through Active Record and other utilities which Ruby on Rails provides.
The overall design of the system followed the Model View Controller pattern. The model was set up using Active record generators to create the desired tables, along with the CRUD operations (Create, Read, Update, Delete). The controller for our system was heavily dependant upon the design of the views and the architecture of ruby on rails. Since each section of the project was its own “window” inside of the browser, partials were used to render each individual section so that they could be manipulated individually. This created limitations on the flexibility with which the controllers could be designed. The overall design of the system is included below in a series of diagrams outlining the different sections of the design.
The team selected two metrics along with the required time and effort metrics. Slippage was chosen because the team wanted to know whether or not they were not they were on schedule. HTA was used because the project sponsor was worried about the performance of the application.
The team completed 37.4% more work then was estimated in the progress reports. Overall slippage of the implementation portion of the project was about 12.5% with 15 planned tasks cancelled out of the original 120 tasks. The team also under estimated the worked required for tasks by 3934 minutes of implementation time. A major reason for such an underestimate was because of the new technology and the limited experience with web user interface implementation. This is really evident in sprint three where the team underestimated by 1837 minutes.
HTA results showed a 1.875 to 4.75 times decrease in the amount of operations it took to perform similar effective tasks. The data is only really based off four features of a previous version of the program. Since the major concern of the team was the UI functionality, many of the features that can be used for HTA could not be tested.
Overall the metrics show that the project was a little behind schedule then planned, but the HTA does point to the tasks becoming more efficient.
Product State at Time of Delivery
There were also some smaller features which did not make it into the final system. The first of which is special handling of the backlog inside of the system. Each of the sprints contains a list of the user stories which are being completed during that time interval. On the other hand the backlog is a special case which contains a list of all of the user stories, even if they are on another sprint. Its purpose is to provide the user with a way of viewing overall progress through the project.
Overall the project went very well, and we feel like the entire project was a success. The scrum methodology was the correct process to employ and we feel that this played a large part in the success of the product. Our team enjoyed completing the project and felt that we learned a lot about web based development as well as several new technologies. Most of the group was not familiar with a majority of the technologies which we used, so the learning process took up a lot of time especially in the first quarter of the project.
After the project was complete we discussed how we felt the overall experience in senior project went. Many of the group members felt that while it was a valuable experience, it felt more like having to do work while at school than an actual class. This made it more difficult to rate progress and accurately evaluate how the team overall was performing. It was generally accepted that a successful project with high customer satisfaction would result in a successful senior project experience.