Our scrum
Today I will show you the process of scrum development that we are doing in my team.
As I get ready for the next CSPO, I read Japanese version 1.2 of Scrum Primer.
Based on my understandings, I will make it clear about current my team’s situation and challenge.
We are on February 9th, 2020 today
🌛 Our condition
- Scrum team that belongs to a relatively big-sized (over 100 people) department of a relatively big-sized (over 1,000 people) company.
- one-week sprint
- started about one year ago
🐷 Scrum Team
- Product Owner: one person
- Scrum master: one person
- Team: four people
🐔 Outside scrum team
We are in big-sized departments from relatively big-sized companies, so people outside the teams can help us because they are interested in our products.
The member of the product team
- CS/Sales: one person
- Designers: two people
The members outside the product team
- QA team
- Another team member of the department
- Another department of the company
📆 Our one week
Our sprint starts from Thursday and lasts until Wednesday.
It ends at 10:30 on Thursday morning, because we cannot often meet the Definition of Done by the time of sprint review😱.
Monday
10:00–10:15 Daily Scrum
Tuesday
10:00–10:15 Daily Scrum
10:00–12:00 Refinement
Wednesday
10:00–10:15 Daily Scrum
12:00–13:00 Team lunch
Thursday
10:00–10:15 Daily Scrum
10:30–11:00 Sprint Review
11:00–12:00 Retrospective
13:30–17:00 Planning
Friday
10:00–10:15 Daily Scrum
(Additional Planning, if we cannot finish before Thursday)
⏲ Ceremonies
We do a lot of try and error, especially in refinement and planning.
Refinement
Our goal is to finalize Product Backlog Items(PBI) for the next sprint after we have known what to do clearly so that we can assign a story point to the PBIs.
Knowing what to do is so difficult here that we try to make a list of factors that would affect the estimation.
We try not to make PBI of more than 5pt. We evaluate as good if we can defeat 15–20 points a week. We see it satisfactory if we have killed 15 to 20 pts in a week. We often consider if we can divide PBI into a valuable unit. We are seeing whether Acceptance Criteria(AC) is enough or not in the Refinement so that we can estimate PBI.
PO will end by adding or sorting PBI by the time of Refinement. The title is based on the issue which is often described as “XXX cannot do YYY (so we should solve it)”.For some cases of PBI, we consider about “HOW”, that is to say, how to implement but how to solve. We scrum team consider this idea and PO will make the final decision.
For some PBI needs to consider about “HOW”, not how to implement but how to solve. We scrum team consider and PO will make the final decision.
If the HOW has been decided at the Refinement stage, we will check the AC. Based on the outline written by PO or the prototype created by the designer team beforehand, We will write a simple scenario with the format of “Given, When, Then”. We have recently started to write it. We used to write AC simply at of testing case. It is better to find some irregular case because the format is similar to that of testing case
- It is easier to find some irregular cases because the format is similar to that of testing cases.
- We can consider easily about the task at the stage of Planning
- We write e2e testing codes by Cucumber and Cypress, so it is easier for us to write them by Cucumber.
— — —
It is important for us not to be aware of how to implement it in this stage too much. If we come up with something, we take notes.
As a result, we can create PBI as below.
Title:
Users cannot delete saved filter conditionsOutline written by PO in advance:
Users needs to delete unnecessary or miscreated filter conditions, as it is unnecessary.
(with URL of Adobe XD)Scenarios written by "Given, When, Then"
Given: Users who have browsing list privileges
And: Users are on the page
And: The filter condition "Filter Condition A" exists
When: Users click the "Saved Filter Conditions" button
And: Users hover at the "Filter Condition A"
And: Users click appeared trash box icon
And: Confirmation modal window is appear
And: Users click "Delete" button
Then: Success toast "The filter condition was deleted" is apper
And: User clicks "Saved Filter Conditions" button
And: The filter condition "Filter Condition A" is not exists
Planning
Planning consists of two stages: Planning1 and Planning2.
Most of what we do in Plannig1 is just to select PBI which will have been done by the end of next sprint. To be more concrete, we check the availability in our team for the next sprint and choose PBI based on average velocity.
At this point, PBI has already been in order by priority so that all we have to do is choose PBIs from the top of the list.
Planning2 is the most challenging and takes more time than any other stage so it has room for improvement. We feel like we are getting better each week.
In this phase, our goal is to divide this PBI into tasks called Sprint Backlog Item. A unit of SBI should last less than thirty minutes
The process is as follows.
1. Reverfication of AC
2. Division of PBI into SBI
3. Verfication of between AC & SBI
4. Three minutes' retrospectiveVerification of AC🉑
It takes about two or three minutes. We confirm if PBI is ready to be divided into tasks by checking whether or not the AC has any missing or unconfirmed things.
If we realize a lot of unknown information about how to implement at this point. We change the PBI into Spike. (Of course, we can also create Spike task at the Refinement phase)
Division of PBI into SBI 💛
PBI has a story point(SP). When we divide PBI into SBIs, we set the time box around 8min/SP. However, currently, we cannot finish the division on time. In that case, we can extend the time until we have finished the division.
In this stage, we pay attention to the following points.
- A unit of SBI shouldn’t be over 30 minutes
- Recognition about SBI should be shared equally in a team
- Not to miss to list any task
To do these things, we identify where and how to implement while looking at the code together.
If we notice there are some bad implementations, we also create tasks for refactoring likewise.
The flow of divisions is as follows.
- Create tasks for the testing based on the scenario “Given, When, Then”
- Create tasks for the front-end based on number one on the list
- Create tasks for the server-side based on the needs of the front-end task. For example, create or edit endpoints for getting some data.
- Create tasks for calling APIs from the front-end
- Create server-side tasks called from number four on the list
- Repeat from number two to five on the list.
Comparison between AC & SBI 💯
After we have finished the division for a PBI above, we cannot help but proceed to the next PBI. However, we often miss some AC so we arrange for the last phase to check AC for one minute.
We check all SBI’s from the aspect of whether we can demand AC by finishing all of that. It is lucky to find some missing tasks, if so We just set the timer again and return to the previous stage.
Three minutes’ retrospective 👩🍳
This is our most agile process. We schedule the retrospective just after finishing the division for three mins. We list up some pros or cons of the last division to improve the next division.
Sprint Review
We do the sprint review with CS and Sales team as well as the Scrum teams.
The purpose is not just a demonstration. but, as written in Scrum Primer, to share advice or insight among each other.
By the way, for our team, there are not relations between the review and release. We immediately release PBIs that meet DoD.
Agile Retrospective
We consider problems that have occurred until the last sprint to improve the following sprint.
We analyze the problems and decide a TRY (how to solve them), and also decide who does what in most cases. Sometimes, our Working Agreement is also updated in this phase.
It is difficult to remember what happened until the last sprint because we have poor memory. So we often write what happened to shared notes during the sprint.
Daily Scrum And Daily Working Hours
Our Daily Scrum starts from 13:30 of every weekday. It is a general Daily Scrum. We share what we’ve done, what we’ll do, and something trouble.
We post sticky notes of SBI on the wall. At Daily Scrum, we mark to tasks that will be done by the next day and take the stickies to each seat.
It is easy to understand how many tasks we can do in one day because the unit of one sticky is 30mins. We use a timer to measure the time while doing tasks, and when complete a take we write the actual time spent.
Conclusion
I was going to describe the current state of our Scrum casually. I realized we had an immensely rich week and it was too long to write about everything. For some parts, I could not describe in detail or get messy. I hope to write another one! Sooner or later, I will write about our evolving Scrum development as “Our Scrum 2”.
