{"id":2839,"date":"2020-08-24T16:02:20","date_gmt":"2020-08-24T20:02:20","guid":{"rendered":"https:\/\/agileadam.com\/?p=2839"},"modified":"2021-05-26T11:18:00","modified_gmt":"2021-05-26T15:18:00","slug":"actionable-task-naming-reduce-confusion-increase-speed","status":"publish","type":"post","link":"https:\/\/agileadam.com\/2020\/08\/actionable-task-naming-reduce-confusion-increase-speed\/","title":{"rendered":"Actionable Task Naming – Reduce Confusion, Increase Speed"},"content":{"rendered":"

I’ve worked on many teams across many task management systems. One practice that has consistently brought clarity to our projects is actionable task naming<\/em><\/strong>. That is, naming tasks in a way that makes them assignable<\/em> and actionable<\/em>. This will reduce the number of false assumptions made, and the amount of time it takes people to interpret a task, every time<\/em> they encounter the task!<\/p>\n

Doing this is easy, too.<\/p>\n

Instructions:<\/h2>\n

When you’re writing a task, say these words first (in your head): “I need you to…” or “I need them to…” or “John needs to” \u2014 you get the gist. It’s that simple (most of the time).<\/p>\n

Example 1:<\/h2>\n

Instead of Hero image on the homepage is too large<\/span> you could say Make homepage hero image smaller<\/span> or Homepage: make hero image smaller<\/span> or similar.<\/p>\n

Note that I often remove the word “the” (Make the<\/em> homepage hero image smaller).<\/p>\n

Example 2:<\/h2>\n

This time I’ll illustrate why this practice is useful<\/em>:<\/p>\n

Address field is optional<\/span>\u00a0 \u2014 does that mean it is currently optional but needs to be required? Or does it mean that it’s presently required but needs to be optional? I don’t want to have to ask myself that question each time I pass by this task. It’d be much easier to understand the intent\/issue if it was written Make address field optional<\/span> or Make address field required<\/span> or similar.<\/p>\n

\n

On a Related Note (for Developers)<\/h2>\n

You can use a similar practice when writing version control commit messages.<\/p>\n

Instead of I need you to…<\/span> we use the prefix This will…<\/span>.<\/p>\n

The result is consistent messages that say what will happen when a commit is applied\/reverted.<\/p>\n

Example:<\/h3>\n

Update jQuery UI version to 3.5.1<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

I’ve worked on many teams across many task management systems. One practice that has consistently brought clarity to our projects is actionable task naming. That is, naming tasks in a way that makes them assignable and actionable. This will reduce the number of false assumptions made, and the amount of time it takes people to interpret a task, every time they encounter the task! Doing this is easy, too. Instructions: When you’re writing a task, say these words first (in your head): “I need you to…” or “I need them to…” or “John needs to” \u2014 you get the gist. It’s that simple (most of the time). Example 1: Instead of Hero image on the homepage is too large you could say Make homepage hero image smaller or Homepage: make hero image smaller or similar. Note that I often remove the word “the” (Make the homepage hero image smaller). Example 2: This time I’ll illustrate why this practice is useful: Address field is optional\u00a0 \u2014 does that mean it is currently optional but needs to be required? Or does it mean that it’s presently required but needs to be optional? I don’t want to have to ask myself that question each time I pass by this task. It’d be much easier to understand the intent\/issue if it was written Make address field optional or Make address field required or similar. On a Related Note (for Developers) You can use a similar practice when writing version control commit messages. Instead of I need you to… we use the prefix This will…. The result is consistent messages that say what will happen when a commit is applied\/reverted. Example: Update jQuery UI version to 3.5.1<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[362,363],"_links":{"self":[{"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/posts\/2839"}],"collection":[{"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/comments?post=2839"}],"version-history":[{"count":11,"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/posts\/2839\/revisions"}],"predecessor-version":[{"id":2887,"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/posts\/2839\/revisions\/2887"}],"wp:attachment":[{"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/media?parent=2839"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/categories?post=2839"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agileadam.com\/wp-json\/wp\/v2\/tags?post=2839"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}