- 260609592 - Abdullah Irfan
- 260739353 - Aljulanda Al Abri
- 260803665 - Alexa Normandin
- 260802908 - An Khang Chau
- 260800991 - Antoine Hamasaki-Belanger
- 260775639 - Hyun Su An
- 260606017 - Jingxu (Jack) Hu
- 260678570 - Mahad Khan
- 260630187 - Mustafa Khawaja
- 260617913 - Owais Khan
- 260805143 - Roger Zhang
- 260688512 - Shayne Leitman
- 260795887 - Tian Han Jiang
- 260623861 - WenQi Shi
- 260535376 - Yahya Azami
- 260669715 - Yunus Can Cukran
The first backlog grooming session was the first task accomplished as a team. It took form as a 2-hour meeting where all team members met and established what the product, model and high priority user stories were going to be. For each of the 3 tasks, the team of 16 was split into subteams of 5-6 people. Each subteam then brainstormed ideas for 20-30 minutes. These ideas were finally put in common during a 15 minute roundup where the best ideas form each subteam were presented and the final form of the discussed subject was decided. It was not only a very good opportunity to meet and get to know the team, but also a good way to make sure everyone was on the same page. Indeed, we discovered that one of the priorities when managing a group of 16 people is to ensure everyone has the same idea of the product and where it is going. At the end of this first meeting, each subteam chose 2-3 of the freshly established high priority stories and took on the responsibility to design their acceptance tests (normal, alternate and error flows, examples etc.). 1 or 2 members of each subteam met up again 3 days later during a 60 minute meeting to discuss the acceptance tests, clear up ambiguities and confirm their quality.
Initially, the following backlog grooming sessions were scheduled to happen on a weekly basis, usually Monday after class. However, during busy periods such as when most team members had mid-terms, they happened on a bi-weekly basis. 1-2 team members from each subteam attended and they were a very good opportunity to discuss if the workload for each story was rightfully estimated. As a result of them, a few high priority stories were downgraded to medium priority so that the team could focus on getting the core of the product working reliably.
As explained in section 1.1, at the beginning of the first sprint, the team was split into subteams of 5-6 people. Each subteam elected a captain and selected 2-3 high priority user stories to work on. After establishing all the acceptance tests, each subteam was given around a week to prepare a list of tasks associated with their stories. As per Scrum principles, the tasks were prepared to take 1 to 4 hours and were not initially assigned to anyone. They affected the frontend, backend and testing. The tasks from each subteam were then put in common Google sheet (which took the role of task board) where people could assign themselves to a task as soon as they finished with their previous one. Upon starting a task, a team member was required to change the status of the task from "To-do" to "In-progress", input the estimated time he/she thought it was going to take and the date on which the task was started. Upon finishing, a team member was required to change the stats to "Done", input the actual time it took and the date on which the task was finished. These details helped us estimate what was left to be done and if the size of the tasks were appropriately estimated.
Initially, each of the 3 subteams was assigned to 2-3 stories and assigned with the tasks associated with them. However, the second week of the 1st sprint, we realized it was inefficient since each subteam had team members working on the frontend, backend and testing. Therefore there was an unnecessary amount of confusion and merge conflicts between subteams. Also, the tasks were often inaccurate since they had been established by people who didn't have a lot of experience in "field" of the task (ie: frontend). It was thus decided to reorganize the subteams into one for the frontend, one for the backend and one for testing. The task list (Google sheet) was also reorganized as such. This change made it easier for subteams to understand what new tasks needed to be added and improved their accuracy (both subjectwise and timewise). New tasks were added whenever needed, but mainly after the backlog grooming sessions.
At the beginning of the project, as explained in section 1.2, subteams were assigned to high priority stories and took on the responsibility to create tasks of around 1 to 4 hours. This process was purely based on past experiences. Then, the teammate assigning himself/herself to the task had to input an effort estimation before starting the task, once again based on past experiences. It was, for most of us, the first time we had to create tasks in a Scrum environment. Therefore, the tasks created during the first half of sprint 1 were very inaccurate. As an attempt to fix the inaccuracy, tasks which were too big were split into smaller ones and those which were too small were merged into bigger ones.
As development advanced, each team member gained experience and got better and better at estimating task effort. The notion of "completed story" also got clearer. In the beginning, nobody really knew where the project was going. It was therefore hard to estimate when a story was done. As the product evolved, the purpose of each story got clearer and it was easier to assign a story as completed. In the future, one improvement could be to estimate each task effort collectively (instead of individually) using estimation tools such as Planning Poker.
Daily standup meetings are a critical part of the Scrum methodology. It was however impossible for us to organize daily meetings because all members of the team had very different schedules. Therefore, we decided to replace them with captain meetings 2-3 times a week. As previously mentioned, each of the 3 subteams elected a captain, who represented the subteam during the captain meeting. During it, captains would provide updates on what had been done since the last meeting and what was next. They would then relay the information to the rest of their subteam. These meetings did not always happen in person. They could take the form of voice calls or group chat exchanges.
As the semester went on, all team members got busier and the number of meetings per week diminished. It could vary from 1 per week to 1 every 2 weeks. However, the rate of work also diminished. Therefore, the number of meetings was appropriate with respect to the work that was done. When substantial advancement would be accomplished, the captain would notify the others in a spontaneous way, which defeated the purpose of frequent scheduled meetings.
Normally, after each sprint, a deliverable product is due and must be presented to stakeholders to validate the work done. The sprint demo is meeting between the scrum team and the client to show what has been accomplished during the sprint. This practice ensure communication between developpers and customers during the whole process and gives more confidence on both parties that the product developped is what the client desires. For this course, since there is no actual clients, we considered the TA to be the stakeholder which we had to demonstate our work to. At the end of each sprint a meeting was organised between 1 or 2 team members and the TA. During this meeting, our team members would show the features implemented during the sprint and the stakeholders would comment on the state of the application and provide ameliorations to be done.
Our approach to the sprint demo was slightly different than usual. Since we have a team of 16 persons, it was not possible for the whole team to be present for the demonstration with the TA. Only 1 or 2 team members demonstrated the application and gave the rest of the team feedbacks given by the TA. However, we did organise a meeting where each sub-teams showed the work they have accomplished during the sprint so that every team members know what is the state of the whole project.
Sprint retrospective usually occurs at the end of every sprint. The goal is to identify what went well, what should be improved on and how to approach the next sprint. For our team, we organized a teamwide meeting at the end of the first sprint for around 1 hour and a half to discuss what we could improve on and what went well. We organized the meeting in 2 part. The first part, any team member shared their opinon and we wrote a list of every ideas brought up. In the second part, we voted on which factors we should put more importance going into the second sprint. What we learned from the retrospective was that meeting between team captains was more convienent and worked better than trying to organize meeting with all team members. Also, we concluded that for the second sprint, we should put more emphasis on the high priority tasks than we did initially.
Our approach to the sprint retrospective was very similar to the traditional way of doing it. Since it is a single meeting, the team size and the differing schedules between team members did not drastically affect the retrospective's organisation. However, due to the size of the team, we could not keep all the ideas brought up, we had too skim the list down to the essential elements that should be done in the next sprint.
Collaboration between team members is a central concept of scum practices. However, due to the team size (16 members) and the fact that we all had different scedule, our approach to collaboration was different from the usual. First, since it is very hard to coordinate 16 person, we divided our group into 3 sub-groups (Backend, Frontend, Testing). Members whitin a sub-group would meet often and be more in contact with eachothers compared to people in other groups. This made meeting easier to schedule and made meetings more productive since every member could be engaged. Further, the scope of discussion of each sub-group's meeting was more focus which made it more efficient time-wise.
However, it is very important for sub-teams to collaborate together, so our team-wide communication was done through captains meeting. Every sub-team chose a captain which had the job to meet with other captains to talk about progress and relay the meeting's information back to their team. Even if most communication between teams was done through captain meeting, any member could meet with any other member, communication was not done exclusively through captains. We had a Slack group set up which made it easy to easily contact another team member if we had any specific questions which we wanted to ask directly to the person who implemented the feature.
A Done checklist was used throughout both sprints to ensure that the team put focus in the right activities and consequently implement a shippable product. Just before the deadline of each sprint, several team members would meet in order to make sure that certain standards were met:
- Produced code for high priority user stories functionalities
- Project builds without errors
- Code is committed to Git
- Functional, acceptance and unit tests are performed and pass successfully
- Code review is conducted
- Project is deployed to Heroku successfully
This allowed us to keep track of which features were completed and which ones we’re still left to be carried out. This scrum object provided us with a process standardization and better team communication.
As mentioned above, the Done checklist was carried out before the end of each sprint to make sure that we had met all our standards for each sprint deliverable. For the first sprint, the Done checklist was setup 1 day before the deadline and we realized that we weren’t abiding to our development standards. We we’re missing various things and we hadn’t enough time to implement these elements. Therefore, for the second sprint, we decided to set up the Done checklist a week before the due date in order to allocate ourselves more time if any changes or developments were needed. This proved to be a success as we managed to fulfil all our standards with a full week remaining.
Before the start of Sprint 1, all team members assumed the responsibility of a Product Owner. The Product Owners’ prioritized a list of application features that will be required by the customer. It was ensured that each new feature added value for the customer. This list included user stories, non-functional requirements, constraints, deliverables and capabilities. Once each team member had prepared a list, we selected all the common features to add to our Product Backlog. We then added the Who What Why triage to the user stories, prepared a list of acceptance tests with their normal, alternate and error flows using Gherkin syntax. The most popular scale, meter and target were defined for the non-functional requirements. Only the high priority stories i.e. all the items that must be implemented in Sprint 1 were detailed and groomed. A document containing all the high, medium and low priority stories was created so the team members can reference it during implementation and change the priority of a story as the sprint moves on. The purpose of the backlog was to provide the Scrum Master and the Scrum Team a broad and complete To-Do list during the course of the project implementation.
The Product Backlog is a dynamic document. It was actively managed throughout the development cycle. During each Sprint Planning session, the team would decide which backlog items are to be implemented for the next iteration. The estimates for the entries in the backlog were re-estimated at times to make sure it was an accurate representation of the work required. When required, new requirements were added and existing requirements were modified. The final set of requirements within the Product Backlog was developed iteratively, together with the resulting software. As a sprint moved on, some medium or low priority stories were promoted to high priority stories too as their priority increased to ensure maximum value was delivered to the customer at the end of the sprint. At the end of a sprint, the Scrum Master would ensure the team conforms to the done definition for completed backlog entries.
Before the start of each sprint, a sprint planning meeting was held in which the team committed to the work that they would complete during that sprint. Usually the team velocity metric is used to estimate the amount of work that a given team can successfully finish in a given sprint but this did not apply in this case since this was a brand new team with no prior statistics to work off from. Therefore, a reasonable amount of work with respect to the team size and skills was chosen and then the stories on top of the product backlog were moved onto the sprint backlog.
After deciding on the stories to be completed within the sprint, each story was broken down into individual tasks that could be completed by any member of the team on their own within one day. Task breakdown is essential in a team following the agile development paradigm since it removes a lot of potential blockers during a sprint. Any developer who finishes a task immediately moves on the next available one until their are none left. In teams that have fairly accurate estimation skills the work committed to tends to be done at or near the end of the sprint. On the contrary, where estimation skills are not as good teams tend to get better over time as they get more accustomed to the skill of their team and what they are capable of.
At the beginning of each sprints, a meeting was set between all members of the Scrum team to determine the list of tasks needed to be implemented during the Scrum sprint. A sprint backlog task list provided the team members with a means to view the work needed to be done to meet the sprint goal and as a plan to trace the current progress of each individual tasks. The tasks were listed in a Google spreadsheet. For each task, the spreadsheet would show the name of the task, the user story it was associated to, the team member(s) developing it, its current status (to-do, in progress, done) and the start and end dates. Moreover, the individuals developing a certain task would also insert the estimated amount of time and the real time devoted to its implementation. It is important to know that the sprint backlog task list was updated everyday as new information was available. Finally, at the end of each week, several team members would meet to review the tasks implemented during the previous week and discuss if new tasks were needed and which tasks to focus on for the following week.
For sprint 1, we focused strictly on the high-priority user stories and aimed to identify the tasks required to develop these features. In addition, the tasks we’re divided into 3 categories such as Frontend, Backend, and Testing. Moreover, for sprint 2, we wanted to optimize all the features implemented during sprint 1 and add additional features. Again, the tasks we’re divided into the same 3 categories mentioned above. The tasks needed to be implemented we’re mostly determined by the meeting with the Teaching Assistant, M. Khan following the deadline of sprint 1.
The story point burn down chart maps how much work is left to be done in hours of work versus time left during the two sprints. Creation of this chart was based on the Sprint backlog task lists for both Sprint 1 and 2. This chart would be set up with estimates of durations of completion of tasks and later updated with actual duration times to give a clearer and more accurate estimate of work left. This chart works in conjuction with the tasklists to provide a simple visual representation of the work progress, so all team members can benefit.
Furthermore, with a visual approach, benefits arise such as facilitating ressource allocation to tasks that may have fallen behind on progress as it is easier to track task completion than looking up numbers in the task lists.
Throughout this project, not only did we build a versatile platform, but also a versatile and strong team. Most of our team members met each other for the first time during the course and therefore it was essential that we establish a strong relationship between each other before and while working on the project. First, we ensured that the team members were comfortable with technologies that would be used. We built a web platform using JavaScript which has over 60 frameworks that we could’ve used, but we chose the Angular framework because most people were already comfortable with it which also ensured that team members would not feel excluded from the development of the project because they’re less familiar with the technology.
Secondly, besides choosing the main framework, we were very flexible about the other specific technologies development process that we wanted to use. For example, people were free to choose whichever IDE they prefer and whichever development process they liked as long as it produced decent working code. Some people like to debug and test the code in the IDE while others like to debug it on the browser. After all, we are trying to accommodate 16 team members to work together for the first time and produce a working platform, so we had to be flexible to fit in everybody’s preferences while working.
Moreover, as the project progressed and the technical side of the project started to get more complex, the team naturally divided into sub-teams so that we could focus on small individual technical problems, and more efficiently take on relevant tasks for the stories being worked on. Working on these small technical problems meant each sub-team had to work together in person to solve the technical challenges and support their colleagues in the problems that they were facing.
We understood from the beginning that documents are of no value while the platform is not working. Especially in the case of our project, small changes were constantly being made to improve and link code. For this reason, we postponed writing the formal and proper documentation until the end of sprint 2. This meant that the documentation could be written only once, and could be completed properly and accurately.
Throughout the project, we were writing a less formal version of the documentation for internal use. The structure of the platform was changing as we were facing problems and solving them, therefore many of our API components for example evolved and changed a lot throughout the project. This meant that their documentation had to be changed constantly which was very time consuming. Therefore, we opted for first changing the code and API, then updating the docs related to changed section of the API tentatively. Then once we ensured that this section of the API had finished its development and testing phase, and would not be changed any further, we proceeded to write a more formal documentation that is more comprehensive.
Also, it is only at the very end of the project that we added a how-to-use section for the platform after we ensured that all pieces of the platform were working properly and wouldn't be changed significantly throughout the rest of the project sprint.
One of the most useful aspects of the agile process is the fact that the customer takes a more hands-on role in the project. Whereas normally a customer would only be involved in small elements of the project, the agile system ensures the customer is a part of the process and can give regular feedback and input. This results in a product that can be easily tailored to the desires of the customer, and the priority of certain parts of the project can be changed based on the customer's wishes.
In our case, we acted as the customers. From the very beginning of the project, all aspects of the application were considered both from the end-user's perspective, as well as from an in-house project perspective. We started with the basic idea for the app, and figured out what functionality would be needed and desired by the users. However, while working through the sprints, we were constantly asking ourselves the question "is this feature that we are working on something that is needed immediately, or can it wait?". This was us actually re-evaluating the priority of stories, and deciding as users and app-developpers whether the feature being built was really needed immediately, and whether it had been given the appropriate priority. This outlook ultimately resulted in the project being built more efficiently, and with the product being built for the end-user.
In the modern day software industry, new software products and technologies emerge frequently. It has become apparent that companies of all forms and sizes try to push their software products into markets as quickly as possible. Needless to say, whether if the companies have adopted the Incremental Build process or the Waterfall process, their goal is to produce working software for clients where requirements specifications change periodically. Thus, in order for software companies to maintain the competitive edge over their competition, they respond swiftly by releasing new versions of software products to new emerging customer demands. However, this pronouncement, does not solely apply to companies' fervor to anticipate an ever evolving market. It also describes how software companies adapt to obstacles encountered through out their developement cycles. In the past decade, numerous companies have adopted or switched over to the more modern Incremental Build development process. The reason being, this process is agile and it supports the notion of reponding to change when flaws in requirments specification or technology constraints, etc have been encountered. This point, opposes the idea found within the Waterfall process. It specifies that once a sketelton for a software product has been defined, future issues encountered during the design process can not trigger a modification of the original template. Of course, there's always two sides to a coin, the intended purpose for the Incremental build process supports consumer software where as the Waterfall approach corroborates the design process for safey critical software.
4.1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Whenever a new feature or any changes had to be made to our product, all memebers from back-end, front-end, and testing teams worked to deliver the new features as quickly and properly as possible. This was done by serveral thorough meetings regarding the implementation of the new features. Once the decision was made amongst the team members on how the features would be implemented, the back-end and front-end team immediately started working on the new changes. Then the testing team ensured the proper and continuous functioning of the new features with the corresponding test methods. This fast-paced development prioritizes the customer's satisfaction on the quick and continuous delivery of new updates.
4.2 Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
One of the biggest advantages of agile software development is that developers could make quick changes to the product whenever the customer needs them. For example, our team had to change some UI and back-end methods at the end of sprint 2. As soon as the descision of changing some features was made, the changes were implemented in just few hours by our back-end and front-end team. This was done by having each team members work on different features that had to be added, which is the advantage of agile development. Shortly after the features were implemented, our testing team ensured the proper functioning of the features in the future by writing test methods. By delivering quick changes to the product, the customer can have the confidence in their fast-developping product in the competitive application market.
4.3 Deliver working software frequently, from a couple of weeks to a couple months, with a preference to the shorter timescale
We ensured that the user stories that the team committed to in the sprint planning meeting were completed during the sprint. At the end of each sprint the feature being implemented was thoroughly verified through a series of carefully designed tests that included unit, integration and acceptance tests. Given the tests pass the user story branches were merged to master which was setup to automatically deploy to a heroku cloud server where the application could be accessed by the customers.
This operating procedure ensured that the software was always in working condition and it was delievered every two weeks.
Since our project doesn't have a real stakeholder, we work as the usual scrum team without the stakeholder. However in reality, bringing the stakeholder and the development team together can make software requirements elicitation quicker and easier to understand.
Furthermore, in terms of the validation aspect, if some scrum members inadvertently did some work which didn't support the iteration goal, the development team with stakeholder can find those mistakes as soon as possible, so the ultimate goal that all scrum team members should be focusing on is the delivery of working software that possesses value in the customer’s eyes. Anything that pulls the team away from this goal is immediately evident if the team is collocated.
4.5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
Over the course of the 2 project sprints, the utmost priority of the Scrum masters as well as all team members was to maintain an environment that fostered mutual respect and team work. The team was encouraged to assist each other with the timely completion and delivery of tasks. In the case of a blocker being faced, members were instructed to voice them out at weekly meetings or daily stand ups, where other people more experienced in the area would step in to attempt to clear the way, which resulted in efficient task completion.
Team members were encouraged to place mutual confidence and trust in each other to get things done, which led to a significant boost in the team general motivation level.
4.6 The most efficient and effective method of conveying confirmation to and within a development team is face-to-face conversation
Managing a 16-member team can be a difficult tasks especially in terms of figuring out the logistics of team meetings. Establishing a time frame and venue that works for everyone proved very challenging, however during each sprint we made sure that atleast 1-2 team-wide meetings were setup so that everyone could share the progress they had made and that time was also used to integrate the different pieces together to create working software. Team members that were struggling with their tasks paired up with some of the more skillful members of the team to improve their learning of the technologies being used and complete their tasks.
Meeting face-to-face benefited the team immensely because it ensured that everyone had the same mind map of the direction in which the software was headed and it also provided a great opportunity to brainstorm ideas on the new features being implemented.
Communicating the status of a project can be a difficult task. That is why instead of lengthy reports, we measured our progress on what was presentable and working in our code. Removing the ambiguity of reports, our main methods of pinpointing faults or sub-optimal functionality was through what was visible in our website's behavior. Coupled with our task list, this allowed us to see what was effectively completed and what needed to be worked on.
By the end of the first sprint, seeing the basic functionality of the website gave us insight into what was going well in our development process and what needed to be worked on more. We used this knowledge in our second sprint to focus on tasks that were higher priority or considered blocking in order to facilitate a smoother development cycle and deliver a polished, well rounded product.
4.8 Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely
An agile team believes in maintaining a consistent pace. This was accomplished through our preparation stage. By setting realistic deadlines, defining our high priority stories and laying out a task list, we gave each member of the team a well defined job to do with plenty of time to accomplish it. By taking the time to plan and lay out the base definitions before the beginning of the project, each member was given ample time to put in their required hours every week. This removed the necessity of pulling un-sustainable all nighters or cramming weeks of work in the final hours.
By our second sprint, we were more familiar with the capabilities of the team, and therefore were more able to set realistic promises on what we knew the team were able to build. If any member of the team found their task to require more hours than they had expected, through our direct communication methods, help was available from our more experienced members, lessening the overall workload and stress for the entire team.
Our iterative development cycle, along with well defined short term goals, facilitated a smoother, consistent development process that will deliver a product of a higher quality than a development cycle filled with harsh deadlines and unfeasible product promises.
Throughout the course of the project, optimal programming and design practices were used. The codebase was modularized and well documented at all times. The design pattern used for the overall application was the model view controller pattern, which helped separate the business logic, data and view, allowing several developers to work simultaneously on the project. The use of the latest front and back end technologies with comprehensive documentation was employed to deliver a robust application, easy to further build upon in the future. Furthermore, we set up an automated testing suite so that future iterations of the project wouldn't break what is already working.
Throughout the whole project, we were constantly evaluating how much effort we should put into implementing our user stories and cut back on time investment into details that wouldn't be crucial to delivering on the main promise of our application. All the "nice to have, but not essential" elements were put into the the "work not done" bucket and by maximizing that bucket, we minimized our output while emphasizing the impact of our project.
Moreover, we did our best to look for technologies that would help us avoid reinventing the wheel, while also sharing among us tutorials and documentation to quickly bring team members up to speed with technologies that they weren't familiar with.
From the very onset of our project, we divided our team into 4 scrum teams to reduce decision-making paralysis induced by working in a large group.
Members were encouraged to join one that would best fit their strengths, insuring that they take pride in their work while also feeling confident about the tooling as much as possible.
Scrum teams were left to their own devices regarding the tooling, design or organizational infrastructure they desired to adopt provided they deliver on their task.
4.12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
As mentionned in previous sections, our team was often reorganized into various subteams in order make the teams and their work more efficient. Between sprints 1 and 2, our biggest rearrangement was done, switching from 4 to 3 subteams. This allowed us to avoid communication errors and minimalize merging issues. This was done following a team meeting that occured at the beginning of sprint 2. After taking the time to reflect on sprint 1, this is an improvement that was suggested and adopted in order to improve our team's efficiency, performance and organization.
Clearly, some parts of our project could be done in a better way, having more frequent retrospectives can reflect how things work on the project, which part got issues, and can give the opportunity for the improvement. Moreover,frequent retrospectives can let scrum member remember the detail of the project clearly, instead of doing the review at the end of the project. However, given the limited time each team member could devote to the project, we did not necessarily take as much time as would have been needed to reflect on how we operated. In an ideal situation, these meetings would have occured more often (every week for example), which would have allowed us to be even more productive with our team members and time.