Reason Become a ScrumMaster
I knowing scrumwise during my 3rd year UDP project, and that's my first time to have an experience about becoming a scrum master.
I found that scrum master is really important in a group and it is actually the core of the team. I cannot imagine that if developing a project without a scrummaster.
But I also know that is really hard to become a good ScrumMaster, but since college is the place that lets us try something new. I decided to give myself another chance.
Also, thanks to all my teammate let me having this role.
Role & Task
My main goal as a scrum master for this application is to keep everything on track.
To achieve this goal I had
- Clearing obstacles by
- look over every single sprint backlog item and this about how they can be achieved and what is the potential obstacles.
- discuss with the teammate whenever I found that maybe is an issue.
- Communicate to product's owner by
- Sending an email to update the customer after every single sprint.
- Tried to arrange the meeting to get feedback from customers and improve in the next sprint.
- Managing backlog item relation
- Knowing how each backlog item relates to each and put some of the pre-backlog items for a huge feature in the sprint before.
- Coaching agile team
- Keep tracking all the tasks on scrumwise which focusing on description and checklist, making sure all the teammate is knowing what they doing.
- Reminding everyone progress and what is our goal is, keep updated progress with everyone.
- Leading scrum meetings and provide support during sprint planning
- Leading the scrum planning meeting and the daily standup.
Major Output
- 1 Aquality V2.0 Project that including 4 component which is a mobile application, hardware device with sensor, backend server with Ai model, admin website to control.
- 3 Release that develops Must and Should have feature in release 1, Could have feature in release 2, and polish the application at release 3.
- 14 Sprint in total crossover the 7 Month.
- 25 Week spending on the project after deduct the holiday.
- 140 Meeting Conducted including daily standup meeting, sprint planning meeting and also release planning meeting.
- 416 Story Point in total and the team having a 20.8 story point per week velocity.
Tools Used
| Scrumwise | Using scrumwise as a eletronic scrumboard that provide us managing the task, burnup, burndown chart, and also calculation of velocity. | |
| Microsoft Teams | The tool we use to communication with the teams, and also hosting the team daily standup and our meeting. | |
| Planning Poker | We use planning poker to help us estimates the story points before we planning our release. |
The Start of The Journey
After the idea pitching stage, we had decided our project will be Aquality V2.0, which is a project that helps citizen scientist determine water quality through the use of insect.
By reading through the Mahara Page for Aquality V1.0, survey manual for Small Streams System, and also a meeting with our collaborator, Centre for Freshwater and Environmental Studies. We sort our our MoSCoW and I create the backlog item for them. In our plan, we will have 5 component in our project which is a mobile application building using react native, an AI model using yolo v3, a hardware device using Arduino and a ph sensor , a temperature sensor, backend server, and an admin site using Django.
We using planningpoker.com to help us sort our the story point by I import all the backlog item we create, and vote by everyone, it calculates all the score vote by the team members then calculate the average and round up to the nearest Fibonacci series. If the point estimation by 2 teammates got huge difference ( for example 2 points and 13 points), then we will stop and discuss why they got so big difference in 2 different views and we vote it again. Then if a backlog item is excess over 8 points and reaches 13 points, then we will make it become epic, split it down into smaller backlog item, and vote it again.
We using scrumwise to track down all the time we spend on the project including meeting times, research times, times for building mahara page, preparation for the presentation and CA submission, and also the time on developing the application. But only the backlog item for developing the application have story points and calculates in the release since the release is the project release.
A Backlog Item
The backlog item details are generate when we planning a sprint, before that, the backlog item is more like a "TODO" task but didn't touch on it how we achieve it yet.
During the sprint meeting, we will first set up a goal for this sprint for what is the major features we want to achieve, for example, our sprint 6 sprint goal is "Setup AI Model", so in that meeting, we will pick up the backlog item that relates to the goal for example backend work on setup the server and hosts it online, frontend work on having the page and step to use the AI model. After that, if some of the teammates got extra time, then we will look at others backlog items that might come out in the following sprint. Then we start to discuss about the backlog item and fill in its description and also the checklist to knowing the "Definition of Done".
At the end, the sprint backlog item should have clear description, and also the checklist.
Release 1 Plan
Currently, we are in our first release phase, and now is at 3rd sprint in this release, and we have 5 sprint in total.
At the first release, we plan to having a mobile application, and a server hosting on amazon elastic beanstalk.
And the goal we want to reach is list below.
- Build the Arduino Hardware to Collect
- GPS Location
- Ph value
- Temperature
- Store All the Historical Data Gather by Hardware
- Building AI Model For Insect Recognition
- Build a Mobile Application
- Login
- Able User Take Photo and user AI Model Recognize insect
- Showing Historical Data
Release 1
During the development of release 1, we found that we will not able to finish all of our tasks because of the Christmas and New Year Holiday, we decide to lower down our scope by delay the help and navigation function for the application into the second release. And that's is the drop down on our burnup chart.
But even though I already lower down the scope, we still a bit behind just before the last sprint start. I had a meeting with the scrum team and discuss should we also remove the sample reviewing function on mobile applications from our scope. But after the discussion, we think we should be able to do it, so we keep it in our last sprint and we just hit on the point on the last day of our release.
Release 2 Plan
After the dicussion with external collaborator and also teammates the following feature is the feature we going to add in our second release.
- Improvement for AI Model that calculates the insect tail to clarify between mayflies and Baetis.
- Adding Group 6 Insect into our application which actually disturbance.
- Having the feature allows the user to upload the image for an insect that lets the admin able review it.
- Having the feature allows the user to upload the image for the river that lets the admin able review it.
- Help Function That allows the user to check the documentation when confusing.
- The survey step for the user to take down the river site details
- Safety Guide and Term & Condition step to help users keep safe.
- Admin Site to review all data.
- Report problem function when AI Model goes wrong.
- And also some detailed improvements.
Release 2
About our release 2, we discuss we Dr. Suzanne from CFES and we found she is quite surprised that we missing the survey component in our sampling process. After the discussion with the scrum team, we found out the problem is we never define our position well about the application we building well.
Our perspective about "Enhance Version Of Aquality V2.0" change during the phase of development, which in my concept I am trying to build a simple application that saves the user time to do the sampling and only trying to discover the region that Aquality V1.0 never thought into for example hardware and AI model, while some of the teammate start thinking about building a new "Aquality" with most function but in a different way present it. That's why when I decide to make the priority of the survey become really low, they don't have to point it out to me.
So after the discussion with Scrum team and also with Suzanne, we now all agree that we are building the new Aquality with the target keep most of the details for the sampling from the Survey Manual , but not following the way Aquality V1.0 doing.
Release 2 Burn Up
Release 3 Plan
By collecting the user feedback and also the advice from the lecturer, we having that our direction is to polish our frontend apps, but having some minor features on our admin site. This is because although we already been suggested no more new features, but most of the feedback we get is on your mobile application side. So our backend got some extra time that able to have some function on it.
- Fix Duplicate Error For Insect Input
- Modify River Sample Model and make it saving current location
- Modify the logic calling openweather API when the mobile application startup
- Modify the river sample details displaying on mobile application
- Modify the review screen after taking the sample
- Adding apps logo on the mobile application
- Fix Ai Model 500 Server Error
- Add all the API into github action CI pipeline
- Setup the pipeline to deploy the apps to google play store
- Adding Reset Password Feature
- Admin Site add Filter & Export Data
- Admin Site add let Creating multiple users in one goal.
Release 3
Release 3 is the ending phase of our project, and this leads us into a kind of chaos since we actually finish most of the function we plan to do, and starting to polish our apps. We start to discuss about all the feedback and review given by both lecturer and users and picking up the change that we able to do, but some of those advise and feedback we got not enough time to done it and polish it. So the plan mention just now is the final task that we decide to do.
If you look at the burn up chart we having for this release, we having a rise on the target line when the first sprint end and second sprint start, that is because during release before, we found that we always underestimate the task and spend a lot of extra time on it when we didn't plan to do. Our team finish all the task but all of the teammate is under pressure so I trying to reduce the velocity for our team. But the progress we having on sprint 13 is good enough and we able to finish some extra work on sprint 14, that's why we decide to put something more inside the release.