Based on the discussions with your TA during your lab of Week 10, come up with a sprint plan on Github (see procedure for second sprint). This must be done at least 24 hours prior to your lab in the week of Week 11 (Your TA will check Github)
Note the deadlines in the schedules page.
In each lab until the due date, you are going to have a Scrum Meeting with your ScrumMaster (TA), going over the progress you made and the tasks you are going to work on for the next week. The continuous progress will be part of your mark for this phase too, so make sure to make progress each week!
Objectives
The goal of this assignment is to have you go through the second sprint cycle, finish the release and deliver a working product that comprises all high- and medium-level priority user stories and should comprise the low-level priority user stories that your team committed to in discussion with your TA. You will continue to apply the practices learned in the previous assignments. You will use continuous integration, unit testing and acceptance testing to increase the level of quality of the product.
If you received any feedback from your TA regarding your user stories, you should first update your user stories in your Product Backlog Milestone. If you are not sure if this is required for your team, please ask your TA.
This sprint includes all design, coding and testing for the user stories you commit to.
First, you must create a new Milestone in GitHub called Sprint 2. If you haven't estimated how long all of the remaining user stories will take, start by doing that (do rough estimates like you did in Sprint 1 using Planning Poker). Now, assign all of the issues that you plan on working on in Sprint 2 to the Sprint 2 Milestone. You must also create a new Milestone on GitHub called Sprint 2 Tasks. For each user story assigned to Sprint 2, break it down into the tasks that you must complete in order to accomplish that user story. For each task, create a new Issue describing the task and assign it to Sprint 2 Tasks. You must also list the Tasks in the parent user story from Sprint 2 using their Issue Number from GitHub. The Sprint 2 planning has to be completed in the first week so that the Scrum meetings can continue as usual. During the sprint, the number of new issues added should be kept to a minimum, and most of these should be defects. You will start with estimating how long each of your tasks (not just the whole user story) is going to take, if you haven't done so, and then dividing up the work based on the estimates. By the end of this estimation process, you should have estimates for all user stories and all tasks and everyone in the team should end up with approximately the same workload.
You are expected to finish the release and deliver a working product that includes all priority 1 and priority 2 user stories and that also should comprise the low-level priority user stories that you committed to in discussion with your TA. You are also expected to continuously integrate your code with your team and write unit tests for the code that does the parsing.
You must each spend at least 1 hour in the day before your demo performing acceptance testing on user stories that were implemented by another team member. Coordinate your acceptance testing within your team so that all user stories are being tested. When you have tested a user story, comment on the Issue on GitHub to say that you tested it. If you find bugs while testing or anything that you think wouldn't be accepted by your customer, create issues for the bugs (even if you know you won't have time to correct it before your demo).
Each team must update their informal diagram from Assn 5 to reflect the current state of your project's design and hand it in.
Each team must also JUnit test the parser.
Throughout the two sprints, you are expected to make continuous progress, not just the team as a whole, but also each member of the team. Each lab will have a short, approximately 5 minute long, Scrum meeting at the beginning in which you will discuss the progress with your ScrumMaster (TA). Remember the three questions for this meeting to discuss are: (1) What did you do last week? (2) What are you going to do this week? (3) Is anything impeding your progress? The TAs will check that each one of you made continuous progress in terms of completing tasks, coding and writing test cases. You have to prepare for this meeting so that you can quickly answer these three questions, i.e. know what the next tasks are going to be that you want to complete in the next week and what you have worked on.
When you are coding and completing a task, make sure to regularly share your changes with your team (at least twice a week). However, only deliver code when you complete a task and the code does not break the project and compiles correctly, since otherwise you will cause delays and trouble to your teammates.
At the end of the sprint, there will be a sprint review meeting with your Product Owner (TA) in which you have to demonstrate your working product. Each team will have 13 minutes (strictly enforced) to demo the release candidate to the product owner. You should demonstrate all user stories that you have successfully implemented. Go through the most important elements of your Sprint 2 plan with the product owner and show how they were implemented.
I highly recommend that you practice your demo before you meet with your product owner. It is your responsibility to make sure that you demonstrate all of the user stories that you have implemented. It is ok to bring notes with you so you don't forget anything. (The TA might also ask you questions about your implementation and design. These questions will be directed towards individuals, so you should have a general idea about the project, its implementation and design.)
As part of your project, you are expected to complete a document which discusses the trajectory of your project. See assignment 8 for more details
Each person needs to submit a peer evaluation at the end of the sprint. This evaluation is individual and not shared with the group. Please submit this evaluation as soon as you finish your sprint review meeting and before midnight on the day of your final demo.
You can find the peer evaluation online on the project page. The peer evaluation will influence your overall grade for Sprint 2.
Second sprint plan on Github (worth 10 marks)
A design diagram showing how your system works -- any combination of UML "languages" is fine. This is due at the start of lab in week 12.Â
Regular individual contributions by completing tasks and commiting your changes (each week, as discussed in Scrum meetings).
Use of JUnit tests for the parser.
Evidence of acceptance testing (comments on the GitHub issues for your user stories for each team member and defects generated during this alpha testing, no major defects should remain undetected).
Final demonstration of your working product with all the user stories planned for this sprint (see deadlines page)
The release candidate (doesn't need to be explicitly handed in, we can get it from GitHub).
Each one of you has to have filled out the peer evaluation form and submitted via handin (see deadlines page for due date).
(10%) Peer Evaluation (helpful comments and having done the evaluation). NOTE: If you do not hand in your peer evaluation, you will receive 0/10 on the peer evaluation mark.
(15%) Continuous progress: regular individual contributions:
Reasonable code contributions
Reasonable fraction of the entire team workload
Participation in the Scrum meeting (also being prepared for it)
(10%) Design Diagram of your system
(65%) Product and Demo
NOTE: the individual mark on this part will be adapted according to the peer evaluations, i.e. the peer evaluation will be used as a percentage-multiplier in calculating your demo grade.
Demo process: 10% (Preparation, professionalism, lack of errors)
App external quality: 40% (features, UI, usefulness)
App internal quality : 15% (tests, code style, code smells)