Publishing Casual Trello and Casual Spreadsheet
I made my Trello, which visualizes tasks to be done in private time, and the spreadsheet that manages measurement data of my personal sprints public.
→ Currently private.
I've been thinking that I want to make my activities as an engineer as open as possible, so I decided to make them public.
The reason I think this way is that, both before and after becoming an engineer, I've always wanted to know what other engineers are studying and thinking about. There might be a feeling somewhere that I should show mine before asking to see others'.
Reviewing Task Management
I've been visualizing tasks with Trello for about 2-3 years, but this year I changed my operation to properly label, divide tasks, and estimate them, and started trying to measure them with my personal sprints.
The reason I started this operation is that I wanted to make my skill improvement more efficient.
Until now, my operation was just like a simple to-do list, without much consideration of priorities, just doing tasks as I wanted.
In situations where I wanted to do this and that, I often ended up completing only 1-2 tasks after trying various things, which I felt was not good for my time management or mental health.
Amidst such casual operations, I loosely experienced Scrum development and realized daily that there isn't enough time in life for this and that, so I felt the need to operate more efficiently and balanced, leading to a review of my operations.
New Task Management Operation Policy
Within the sprint I set for myself (1 week), I measure how many roughly estimated tasks I can complete.
The estimation effort is in days rather than rough hours. I thought it would be better to estimate by dividing tasks into hours for accuracy, but private time often has more interruptions (urgent matters, chores, etc.) than company time, so sometimes it's not as flexible as it seems. (Being single, it should be even more challenging when building a family) Therefore, instead of estimating by hours, I decided to use days to allow for a larger buffer.
I treat this time estimation like story points and visualize in a Spreadsheet how many tasks I completed in a week and what the total estimated points are.
Since a week has only 7 days, if the total points exceed 7, I can roughly conclude that I worked hard that week.
The purpose of starting this measurement is not to increase the amount of tasks completed within a sprint (throughput) but to become stable in completing tasks within a sprint.
Achieving more than a week's worth of results in a week is good, but aiming for that level of results every week is not a realistic goal. The challenge I recognize is how to maximize throughput within unstable private time.
By ensuring a cycle where I can say, "I have various dining plans this week, so I should be able to complete this amount of tasks → I did it!", I want to use my time efficiently and improve my skills nicely.
Impressions
I think the purpose of a product's sprint review is to maximize the product's value, but I believe that an individual's task sprint review (though it's just measurement) can be seen as maximizing one's skills, so I want to try operating it for a year to see what happens. (The detailed operation policy might change during that time)
Side Note
About task creation.
I have a rough idea of what I want to do, what I should do, and what would be good to do in my head, so I try to create tasks for them. I don't create tasks on specific days; I create them whenever I think of something to do, whether during work or while out.
Things I want to do are those that pique my technical curiosity. Things I should do are necessary for work or things that would cause problems if not done. Things that would be good to do are those that might bring good results in the future or impact my career. Investment activities.
I consider tasks that overlap these three as the best tasks for me, but I feel like I'm mostly doing what I want to do.
