Somehow, after we are forced to do this, and got familiarised with it, we started to enjoy it. We were proud of our team velocity acceleration too!
I still can't differentiate or identify what scrum, agile, and bla bla bla is, but I think we did the estimation and planning right. It helps in our projects and sprints planning.
You could visit Wiki's page on Planning Poker or continue to read this.
I am no longer a developer, and the team dismissed long time ago. Anyway, for me to explain this easier, I will use present tense in the following. :)
Our team consists of a Project Manager, a Product Owner, a Scrum Master, who is also the tech lead of the developers, 4 other developers and 2 QAs. It starts with the features or backlogs that are selected for the sprint. We do a brief study or understanding the features, then start to have a planning session. (I am so tempted to do this in list format at this point...)
In the planning session, all of us got into a meeting room. Each of us are given a set of Fibonacci sequence deck. Project manager is there to ensure our process is done correctly. The Product owner is also there to clarify if there's any uncertainty.
In the first and foremost planning session, we start to identify the easiest task among the selected tasks in the sprint. This will be served as a reference to plan for other tasks. Let's say, this task is to add one personal detail field in a form. We will discuss what's need to be done for this task.
1. Add a new field in the personal details form
2. Is it compulsory field? If so, what's need to be filed for existing database? Or shall we enforce it in the next user update only?
3. Any change to new registration?
4. Which table of the database impacted? SQL query to add and/or pre-fill the field.
3. What is the scope of testing? New user creation? Existing user update? Existing user's details value?
4. Any impact to Autotest? (Pretending we have Autotest ready)
This might be a score 1 or score 2 task. Our planning includes sub tasks to fulfil all of the above, and includes further research if required, unit test write up, unit testing, code review, negative testing, buffer for a fix if needed (I remember we have 20% allocated for this).
We continue with the second task. If a task is too big, say we score it 55, 89 or even infinity, we will break it down to smaller tasks and do estimation again.
Once this is completed, I think we then associate 1 point to 3 or 5 working hours at the beginning. Then we start our sprint.
In the next sprint, if there's no simple task to be assess as benchmark, we'll use the first or previous sprint simplest task as benchmark to estimate for the task. We, as a group, including both developers and QAs, do the estimation together. Developer will express how complicated in the implementation, the impacted area, could be front end or back end only, or both front end and back end, and scopes needed to be tested. The QA will identify roughly how many test cases, complexity to the change of Autotest if required, and how much time or effort of the test cases would be. Then we score the task as a whole, from research and study to QA test complete. The estimation is based on, junior-level in the team. Because the tasks should not be dependent on one particular developer or QA. Anyone would pick up the task when the resource is freed up.
Again, we will associate the estimation with 3 or 5 working hours to complete our sprint planning. 20% additional time added to the planning for bug fixes and re-test.
At the first and second sprint, we over estimated. That is normal. We slowly adjusted. It could be due to experience and we are more familiarised to the platform. It could be the 1 point associated with 5 hours is too much. It could be we have more seniors than juniors in the team. That doesn't matter. We complete the committed tasks together.
As more sprint to come, you will get to know how to score the task. The velocity, is number of story point (poker point) that you can finished in a sprint. As you get familiarised with this, and also the platform that you are working on, you can complete more story point in a sprint, with same time and resource. This is how we see the velocity improvement.
Let me give an example of how this is done.
Say, we are going to support a new feature for our system, which is required to support refer a friend marketing campaign.
With this, we won't be able to estimate the effort that is required to complete this feature. So, we will do a task break down, and also clarify with PO if there's any uncertainty.
| Task | poker point | remarks |
|---|---|---|
| Refer a friend button | 1 | This button is required on home page as a highlight. This is identified as the simplest task, and would be served as the benchmark to plan for other task. In details, the dev need to create a button on home page, link this button to refer a friend form. The home page UI needs to be adjusted, so it looks harmony with the rest of the content of the home page, while need to be stay eye-catchy. QA needs to ensure the button appears at the right location, and if any image is used, it is displayed accordingly. |
| Refer a friend/friends form | 3 | This include the form page, sending email to recipients with the right content and referral information. |
| Add referral field in member's table | 1 | This is simply to have the table adjusted to hold referral information. The update of this field will be handled in the registration. |
| Track of # of successful referrals | 2 | New field in member's table, CRUD functions. |
| Changes on registration form/process | 3 | The URL triggered from email will have referral's ID. Handling of the ID and referral field here. |
| Promotion page of refer a friend campaign | 3 | Marketing personnel will provide the details. This will be a new page on the website, to be linked to the refer a friend form and etc. Note, this will be more work on developer than QA. |
| Token of appreciation distribution system | ∞ | This is a big task, need to further break down. |
Some bonus, if you have a cooperative team. Our team start with Developer do the coding, QA do the test scripts/steps documentation. If any feature is ready to be tested, QA can start to do the test. When Developer finished coding, unit testing, code review, the developer will take up testing tasks by running the test scripts/test based on what QA documented earlier. If bug found, developer will resumed as developer role to fix it. So, both Dev and QA time and effort spent balanced in a sprint, and end the sprint together.
I am not sure how this is done in other company. I must say, I joined the best team back then.
There are teams out there plan by estimating time needed to complete the task. Story point is the timed-estimation. So, if you have 5 person in a team, one sprint with 20 working days, and you are trying to do this kind of planning, your "velocity" is always 5 * 20 - (leaves or other non-related task allocation time). By the way, yes, I know it's called capacity. And this is making the velocity == capacity. Also, if developer and QA did their own estimation, based on their own understanding of the task without any constructive discussion, it could be they have their own understanding of the requirement. I could just say, "Hmm.. OK, that's an alternative." You can't wake up a person who is pretending to be asleep.
Yeah, this post starts one of my 2020 resolution, to start writing about "My tech thought".
No comments:
Post a Comment