Each product has its own value, and it is your responsibility to deliver the values to the users.
As someone who works in the tech industry, we must adapt to rapid change. on my previous job as a game programmer in my indie game studio, we do not use any methodology in our workflow. We just create the Game Design Document and rarely track our progress. It causes problems in management level and product shipment. There are many games that we can not ship because we do not have proper planning at that time.
I just listen about Agile in College, Scrum and other methodologies but never used it practically. At that time I thought it did not fit our need. But it turns out, that we need it and we could ship more product if we use it properly.
Now, in my day to day job as Tools Programmer, our company uses Agile so I follow the process. But since the team I am in is a new one, and I do not know properly about Agile, the clear value of the product I am working on I just do everything that my senior told to do and the sprint became task-based. I do many tasks but I did not have a clear goal is this task following the goal since having no clear vision of what kind of value this product want to deliver. Until I reach a point where I did not know what is future planning for this product.
Until my senior who created the product/tool, I maintain said that our product life cycle is still not clear and we can deliver the values to the user. We try our best to improve our process, from tracking feedback from our user that is programmers in our company. And we want to use it as our reference on sprint planning. But we could not execute it yet, because of Christmas and new year holiday.
In this new year, my senior came to our team as a Technical Product Manager to improve and fix our process and transfer his knowledge so we can deliver our product values to the user.
Value-Based, not Task-Based
The first thing we need to know is the values of our product, they are usability and reliability. We should deliver a product that can be used regularly with almost zero effort so the user can reduce their development time and focus on the task they need to be done. While convincing our user that they can rest and not worry about our tools. We sync our value with the user needs, clear goal and prioritization.
Sync to Goal
Since we know our value, we can decide our sprint goal better and use daily huddle as a process to sync our task with our goal and other team members. We used the feedback from the tracker and created user stories from it, let say our user want to use Firebase features easily, we can make these user stories
As a User, I want to use Firebase feature without having to struggle with the implementation
Definition of Done
This one is one of the difficult things that I do not understand before, we do not know when is a feature is done. First, we must define who is the user. Let say our user want to use Firebase features, so we can make these user stories
As a User, I want to use Firebase feature without having to struggle with the implementation
So when the product is done? Is it when already finish implementing the Firebase into a module? or when QA already tested it? Nope, the product is called done . . .
When the user can use the Firebase feature from our module easily and they do not face any error/bug.
It is a good approach to ask the team member about when this feature is called done rather than fill it by yourself because it will improve the knowledge and experience of other team members.
Adapt
Yes, we define the goal, but sometimes there is something happen so suddenly and outside our team planning. For example, when we must support Android 64 bit. So, we pivot our goal and focus on providing support for Android 64 bit. Use your goal as guidance, not something you must follow and can not be changed. But we also need to filter which one we need to do it now or not. Because sometimes your user will say like,
User: “Dude, can I have these cool features?”
Developer: “Well, let see . . . nope”
We must make sure, is that request pretty important? or is it following our product principle or values? if no then we do not need to that. But it does not go against that, and we still can do it on next sprint that we do not need to make a pivot.
Sprint Planning Process
Let’s use the example above, let say user want to use Firebase feature easily without struggle with its implementation. So we can make this user story,
As a User, I want to use Firebase feature without having to struggle with the implementation
Definition of done: When the user can use Firebase features in their project from our module without any difficulties and bug/error.
And we can make user requirement from the user story above,
1. Create a module that implements Firebase features that are needed by the user
2. Make sure that the module is bug-free and no error
3. Create a manual about how to use the module
After we have user requirements, we decide the weight of each user requirements. We used Planning Poker MX to decide our weight, each team member decides their weight for a user requirement and show it at the same time. When we have the same value, e.g 13 for Create a module that implements Firebase features we agree that this user requirement weight is 13. And if we have a different one, each team member will say their reason why he/she give that weight. After we know each other reason we can agree with the weight value.
1. Create a module that implements Firebase features that are needed by the user (13)
2. Make sure that the module is bug-free and no error (8)
3. Create a manual about how to use the module (5)
At this point, you can let the developer break the goal into developer requirement,
1. Create a module that implements Firebase features that are needed by the user (13)
* Design Architecture for the module
* Implement the Firebase features
* Create APIs for the user to use Firebase features
2. Make sure that the module is bug-free and no error (8)
* Ask QA to test it
3. Create a manual about how to use the module (5)
* Write a clear manual on how to use the module
* Publish it on somewhere that visible to your user
Now we will know the weight of the user story by add all the user requirements.
As a User, I want to use Firebase feature without having to struggle with the implementation (26)
The weight can not decide the priority of a user story, you need to know your user needs and which one is come first. So even this user story has 26 weight, it can be done in the next sprint if in this sprint we have something more urgent to do. In the sprint planning, you need to use user-centric, to create user stories and make prioritization.
At last, the one that will send the values to the user is you. They will not know what is your product value if you can deliver it to them properly.
Thank you for reading this far, I write this based on the knowledge I got this yesterday (Monday) from my senior when he explains about sprint planning. It was fun and I love to share it so other people can read it and I have a note. Feel free to tell me if you have feedback :)