I decided to post my software development checklists on my website for posterity and to be able to share them with others, and I wondered if the ~comp community has opinions about checklists for...
I decided to post my software development checklists on my website for posterity and to be able to share them with others, and I wondered if the ~comp community has opinions about checklists for managing your personal workflow.
For those not wanting/willing to read my linked post, I basically say there that I have built up checklists over time for both implementing and reviewing features at work. I've found they help me stay on task and have often served as guardrails or autopilot to help me produce quality work in various situations.
If you use checklists for your software development, what are they like? If you don't, why not? Any feedback on improving my own checklists is welcomed as well, since I think these are fairly broadly applicable to different software development roles in different organizations.
I (we? the team? the company I guess?) use jira tickets far more loosely. What usually happens is the ticket is filed, more casual, fast-paced conversation happens on slack/zoom, then someone...
I (we? the team? the company I guess?) use jira tickets far more loosely. What usually happens is the ticket is filed, more casual, fast-paced conversation happens on slack/zoom, then someone (sometimes) backfills the tl;dr to the ticket for archival purposes.
This has been my same experience working at a consulting company where there's the team and clients communicate mostly over chat (Slack). Tickets are created quickly as new tasks, features, issues...
This has been my same experience working at a consulting company where there's the team and clients communicate mostly over chat (Slack). Tickets are created quickly as new tasks, features, issues come up in discussion so that they don't get lost. It then varies whether the client / team has time to hammer out the full scope and acceptance criteria then and there or if it's revisited later before starting actual work. It's not uncommon for the client to have a high-level idea, which is good to start tracking and considering early, but hasn't finished thinking through the details. The looser ticket creation has helped keep a lot of things from falling through the cracks. Requiring a lot more detail just to create the ticket tends to result in either tickets not being created (and getting lost) or dummy data getting put in just to satisfy the tool's criteria during creation.
@joplin mentioned a related concern about our tools maybe being a problem. When I say we add acceptance criteria, those aren't required fields on the ticket. We just have a freeform description...
@joplin mentioned a related concern about our tools maybe being a problem.
When I say we add acceptance criteria, those aren't required fields on the ticket. We just have a freeform description field as the body of the ticket. Ultimately we want each ticket to have AC so a tester knows what to test for and a product person can agree on what the results should be, but we're not dogmatic about AC. The idea is just that we want to think through and get some consensus on what the ticket should do to be considered done, before or soon after we start.
Ironically, @joplin was concerned of the exact opposite, which maybe speaks to my ignorance of the variability in ticket tool usage. They were concerned a ticket shouldn't be creatable if it doesn't have AC. I tend to agree with your take, though, that quick ticket stubs help us not forget things.
There are a number of ways that you can organize things, and I don't pretend to know the best. But if acceptance criteria are crucial to the way you work, your tools should be refusing to move on...
There are a number of ways that you can organize things, and I don't pretend to know the best. But if acceptance criteria are crucial to the way you work, your tools should be refusing to move on until they're entered. If acceptance criteria are not crucial to the way you work, then it's no big deal not to have them. Both ways can work, but don't let your tools dictate how you work — dictate how your tools should work to help you get stuff done.
It's an interesting list. For things like this: it feels to me like there's a problem with your workflow in the first place. Why is it possible to even create a ticket without acceptance criteria?...
It's an interesting list. For things like this:
If there are no AC, work with ticket creator to define the AC:
it feels to me like there's a problem with your workflow in the first place. Why is it possible to even create a ticket without acceptance criteria? It sounds like your tools are broken. I'd rather file a bug against the tools and get on with doing my job rather than doing the work my tools should be doing in addition to doing my job. (You have to be pragmatic of course - until the tools are fixed you need to do something.) But this sounds like a good thing to bring up with management to me.
I decided to post my software development checklists on my website for posterity and to be able to share them with others, and I wondered if the ~comp community has opinions about checklists for managing your personal workflow.
For those not wanting/willing to read my linked post, I basically say there that I have built up checklists over time for both implementing and reviewing features at work. I've found they help me stay on task and have often served as guardrails or autopilot to help me produce quality work in various situations.
If you use checklists for your software development, what are they like? If you don't, why not? Any feedback on improving my own checklists is welcomed as well, since I think these are fairly broadly applicable to different software development roles in different organizations.
I (we? the team? the company I guess?) use jira tickets far more loosely. What usually happens is the ticket is filed, more casual, fast-paced conversation happens on slack/zoom, then someone (sometimes) backfills the tl;dr to the ticket for archival purposes.
This has been my same experience working at a consulting company where there's the team and clients communicate mostly over chat (Slack). Tickets are created quickly as new tasks, features, issues come up in discussion so that they don't get lost. It then varies whether the client / team has time to hammer out the full scope and acceptance criteria then and there or if it's revisited later before starting actual work. It's not uncommon for the client to have a high-level idea, which is good to start tracking and considering early, but hasn't finished thinking through the details. The looser ticket creation has helped keep a lot of things from falling through the cracks. Requiring a lot more detail just to create the ticket tends to result in either tickets not being created (and getting lost) or dummy data getting put in just to satisfy the tool's criteria during creation.
@joplin mentioned a related concern about our tools maybe being a problem.
When I say we add acceptance criteria, those aren't required fields on the ticket. We just have a freeform description field as the body of the ticket. Ultimately we want each ticket to have AC so a tester knows what to test for and a product person can agree on what the results should be, but we're not dogmatic about AC. The idea is just that we want to think through and get some consensus on what the ticket should do to be considered done, before or soon after we start.
Ironically, @joplin was concerned of the exact opposite, which maybe speaks to my ignorance of the variability in ticket tool usage. They were concerned a ticket shouldn't be creatable if it doesn't have AC. I tend to agree with your take, though, that quick ticket stubs help us not forget things.
There are a number of ways that you can organize things, and I don't pretend to know the best. But if acceptance criteria are crucial to the way you work, your tools should be refusing to move on until they're entered. If acceptance criteria are not crucial to the way you work, then it's no big deal not to have them. Both ways can work, but don't let your tools dictate how you work — dictate how your tools should work to help you get stuff done.
It's an interesting list. For things like this:
it feels to me like there's a problem with your workflow in the first place. Why is it possible to even create a ticket without acceptance criteria? It sounds like your tools are broken. I'd rather file a bug against the tools and get on with doing my job rather than doing the work my tools should be doing in addition to doing my job. (You have to be pragmatic of course - until the tools are fixed you need to do something.) But this sounds like a good thing to bring up with management to me.