Read Part 1 first!
Write User Stories
You’ve likely heard of user stories or maybe you’re already writing them. Again, there are lots of flavors out there; this is the one that works for me.
As a (role), I want to (some function), so that (or because)…
These take some practice to write and write well. The key attributes that will make a user story excellent and allow it to serve many purposes are:
- The role is well-defined and specific (“bookkeeper”)
- The function is small, precise and its success measurable
- The “why” clause is correct
- Technology-agnostic where possible (we’re solving a business problem)
So for example, an effective user story might be:
As a bookkeeper, I want to easily find invoices open longer than 30 days, so I can avoid incurring late fees.
Notice there is nothing technical in the user story, and we know why the bookkeeper is asking for the feature. Knowing why will likely inform your design choices–or you might even scrap this feature once you know why she’s asking (for example, maybe you’ll add in automation so invoices are never late, to begin with).
Let’s look all the things this user story does for the project:
- Documents what you’re going to do.
- The bookkeeper can read this user story and verify that’s what she’s asking for (collaboration and ownership).
- As you write the code, you have freedom with its design, and you’ll consult the user story to make sure that’s all you’re doing, no more, no less (do what you documented: keep the project in scope, on schedule, under budget), within reason.
- Once you’ve written the code, you can use the story as a test, that you’ll execute as the bookkeeper (delivering defect-free products).
Now close the loop, and document that you did what you said you would. I use a Kanban board to track when things are “done.” The test results serve as documentation, along with any documents I wrote to replicate the code to production. When I deploy, I’ll comment the code with the user story/request # for traceability.
As my son’s Kindergarten teacher used to say, “We’re not perfect, but we try.”
We all make mistakes. I make several, but I know I make less than I would without these tools. If you can see your defect rate going down, that’s improvement. The quality tenant of continuous improvement reminds us to keep striving for excellence.
A simple way to practice continuous improvement is to simply ask the customer for feedback. (If you want to get fancy, write a survey.) This will give you an idea of where the customer thinks you can improve.
Internally, after a major misstep (or major success!), it’s useful to have a Lessons Learned-type process in place to look at the matter with fresh eyes and hopefully prevent errors from occurring again. A low-tech way to do this is the 5 Whys method. Using a whiteboard, state the issue and then ask “why” it occurred. Once you have the answer, ask “why” that occurred. Do this about 5 times, and you’re likely to arrive at the culprit.
Here’s a real-life example (my bad!):
Problem: We had to delay deployment of a new feature because I made incorrect assumptions about the production environment. Why did you assume?
Answer: I thought the dev and production environments were identical. Why?
Answer: I thought the reason for having 2 environments was for accurate testing. Why?
Answer: I assumed the processes in place were more mature than they were and that IT had reviewed a diagram I circulated. Why?
Answer: I never heard back from them, so thought they agreed with my proposal.
Root Cause: I should have taken the time to verify I had the details right.
Wear your quality hat to spot defects and remedy them before they sidetrack the project. Use documentation (it’s not as arduous as you think!) to control your processes, and deliver the correct solution, bug-free, the first time. After a project, reflect/seek feedback so that you’ll not repeat those mistakes, and don’t forget to give yourself credit for your successes. Your customers will see the difference and will feel confident and happy that they placed their trust in you.