I often come across problems that, on the surface, seem like they’d be “quick fixes.” Maybe it’s a bug that could be resolved by tweaking one varia...
For further actions, you may consider blocking this person and/or reporting abuse
Where, specifically does the To-do list live? Who sees it? And what's an example to-do?
Good post, would love some examples.
Good questions! The to-do list should live somewhere that all relevant stakeholders can see it and chime in. That's going to vary based on the team, project, and task, but in general, the more visibility the better.
A to-do should at least have a brief description of the task and some way of tracking who's working on it. As people discuss and begin work on the to-do, it can be helpful to add supporting links, screenshots, demo videos, etc. There are plenty of tools that do this well -- I've enjoyed working with Basecamp and Trello.
I wouldn't worry about trying to conform to any particular format, especially when you're just getting started. I think to-dos should be about getting context out of individual's brains into a shared space rather than adding unnecessary process or bureaucracy.
Thanks!
Teams that are working with Microsoft stack, often use VSTS to manage their backlog. 🙂
"Couldn't you just ..." ha ha. Uuum, how 'bout no?!
But being serious again, something that has worked well for me recently is trying to solve multiple known similar issues/feature request with one over-arching bigger solution, instead of quick fix of very small and specific edge case.
Could be wrong, but I feel I first heard about this approach from Downwell game-dev blog, but also seems to work well for bigger business webapps :)
For sure! It's great when a general solution can address multiple issues at once. I've also found that those types of approaches can lead to more resilient and easier-to-follow applications than a patchwork of quick fixes.
It's of course easy to go crazy and re-write stuff just for the sake of it, but it really feels like good practice, as dev, you're not writing throw-away code and can be proud of your nice neat code, and business also gets a re-usable feature that now can grow and solve even further problems, probably much quicker in the long run than doing 10x quick fixes.
I like the part about easier-to-follow app, I might sneak that into my next board presentation as additional benefit :P
"but through discussing the to-do, I’ve learned that a change wasn’t necessary after all." Chesterton's Fence is a handy principle regarding this.
Great article!
I agree, writing a public to-do really improves the communication inside the team.
Also, that way, if you are stuck - you can get help from team members that saw your code and might have interesting ideas to share.
At my workplace we use github enterprise where we log our TODOs as issues. This kicks off a discussion which may lead to it being worked on.
Nice! I recently moved to a new team that uses GitHub issues heavily. It's been a little painful retraining my muscle memory that's so used to working in Basecamp, but the goal is the same: getting to-dos out in the open.