Interruptions kill productivity in any work environment and it’s no different if you’re working from home or not. In this post I share some of the techniques I’ve been using for several years to help manage interruptions:
- The Pomodoro Technique
- Educate your environment
- Replay what happened prior to the interruption
The Pomodoro Technique
Check out The Pomodoro Technique website in case you’ve never heard of it. Besides working in focused 25-minute blocks, the main thing I got out of this technique has been tracking interruptions and classifying them as:
- Internal: have I stopped working on my task because I saw a social network or email notification? Or maybe because I opened the web browser to check one thing related to my task and ended up reading the news instead? Such interruptions are considered internal because I didn’t have self-control and focus to stay on target. That’s easily addressed by shutting off all notifications, at least during that focused time.
- External: have I stopped working on my task because somebody walked up to my desk and started talking to me? Or maybe because I got pulled into some unplanned meeting? These are external interruptions brought to me. They can be addressed by educating your environment. More on it further down…
I can’t stress enough the importance of taking note of the interruptions, classifying them as internal or external, and finding ways to prevent them from happening again.
Educate the Environment
Let your environment (physical or virtual) know whether it’s ok to interrupt you or not.
- Let people know that you’re in “do not disturb” mode: put up a flag, a post-it note, your headphones… whatever your token is, just let people know. Don’t forget to put it away when you are available (use the status feature if you’re working from home);
- Let them know why, if necessary: Depending on the situation, when others know why you’re not available, they are likely to help to keep others from interrupting you;
- Let them know what they should do if they need you: if they have an urgent situation, let them know to interrupt you by all means. If it’s not urgent, let them know to drop a note such as “I need 5 minutes of your time before 3pm today…”. They can leave a post-it note on your desk or a message in whatever communication channel has been clearly defined. Make sure to get back with them (this is essential for the system to work!).
This is what I have right outside my home-office…
Replay what happened prior to the interruption
A big problem with interruptions is that it takes us an average of 25 minutes to return to the original task. If my task is done on the computer, I’ve found ways to decrease the time it takes me to get back “in the zone”:
Take screenshots: I’ve been using TimeSnapper for a long time. I blogged about this 13 years ago! In nutshell, the tool takes screenshots every 5 seconds. If I get interrupted, I can use the tool to replay the screenshots and jumpstart my mind to put me back in the zone.
Git commits: I’ve also used my commits in Git to get back up to speed after an interruption. If I was heads-down working on a user story, implementing my tests, making them pass one by one, and committing after each step, I can then look at the commits to see the work I had done prior to the last interruption, which helps me get back in the right frame of mind.
If you take anything of this post, this should be it:
- Realize you’ve been interrupted;
- Determine whether it was an internal or external interruption;
- Isolate the source of the interruption;
- Put some system in place to prevent the same kind of interruption to happen again;
- Some interruptions can’t be prevented, so put a system in place to recover from it quickly.
Whenever we teach/learn how to write user stories, we usually use the “As a… I want to… So that…” format, like so:
As a <persona>I want to <have a capability>So that <value this story brings>
It’s not uncommon we end up writing stories such as this one:
As the system
I want to remove duplicate entries from my address database tables
So that I don’t have duplicates
I hope that story has made you cringe. If it didn’t, what’s wrong with you?
Thinking about the Purpose of a User Story, let’s ask:
- How does the story above help the business either make or save money?
- Is “the system” a valid persona? (…maybe one day it will be, I guess…)
- Why is it important that addresses are stored in database tables (as opposed to documents or CSV files)?
- What’s the problem with having duplicate addresses?
- How does that story bring value to the business?
What if we rewrite the user story in this manner:
As the marketing manager
I want to send direct mail with no duplicate addresses
So that I save on mailing costs of marketing initiatives
- The story brings value to the business by saving on mailing costs;
- It makes it clear that the value is important to marketing managers;
- It indicates that sending direct mail for marketing initiatives is the business operation affected by the story;
- No technical details are specified;
- Any non-technical person can understand it.
With all that being said, here’s a question: what’s the single most important part or sentence in that story?
Here’s the answer: the “so that…” part. It is the part that tells us the purpose of the story. The why. It tells us how the story brings value to the business. It tells us why somebody is willing to pay money to see that story implemented.
Last But Not Least?
So, why is “so that…” the last part of the story?
Why build the suspense?
We shouldn’t expect anyone wanting to create cinematic versions of user stories, so let’s cut right to the chase and highlight the most important part of the story, by rearranging it like so:
In order to save on mailing costs of marketing initiatives
As the marketing manager
I want to send direct mail with no duplicate addresses
Right there, Start with Why. But first, let’s give credit where credit is due: I’ve first learned about changing user stories to go from “so that…” to “in order to…” on the Cucumber website. It made a lot of sense to me (it still does!) several years ago and I stuck with it.
That approach is so ingrained into my way of thinking that when I see a story written as “As a, I want to, So that”, I end up reading it backward (by reading the “so that” part first).
Why does it matter?
Over the years, I’ve sat in many meetings (Sprint Planning, backlog refinement/grooming, etc.), where the leader reads the story out loud following a pace that looks somewhat like this:
- “As a…”, spoken kind of fast, but the words can still be clearly heard;
- “I want to…”, spoken slowly, emphasizing the “want”
- “So that”, spoken fast, words hard to distinguish. More of a slur, really. That’s it: the person is slurring, not speaking.
But wait: if the “so that” is the most important part of the story, why are we slurring through it like that?!
There’s a lot of focus going into the want part, but not as much going into the why it’s wanted. In fact, I’ve seen a lot of time spent discussing “want this” and “want that”, and from little to almost no time spent on the why.
First Things First
My recommendation to people has been to start every user story with “In order to…”. If we don’t know how to finish that sentence than we don’t know what the value of the story is, and therefore, no time should be spent on anything else. Who the persona is (“as a…”) and what is wanted (“I want to…”) become irrelevant if the story lacks a strong why (“In order to…”).
In the example story above, after finishing the “In order to save on mailing costs of marketing initiatives” sentence, someone might raise a hand and say something like “I’m aware of a special service deal where we get significantly reduced shipping costs over X number of letters”.
At that point, the focus of the conversation could turn to figure out if there’s any chance that the cost to build and operate the new future would be more money-saving than the available service deal. Yes, software is NOT always the best solution, can you believe it?
Consider Adding Context to the Persona
I’d also recommend considering adding a context along with the persona in a user story, as described in this blog post. Take this contrived example:
In order to end my hunger
As a person
I want to get some food
Is the person really hungry for food? Maybe the person is just thirsty (the feeling of thirst and hunger can be very similar), so while the person may “want” some food, maybe what she “needs” is water. Adding some context to the persona would help clarify things:
In order to end my hunger and not get a stomachache
As a person who hasn’t eaten for 18 hours
I want to get some light food
Often, after adding context to the persona, we may end up seeing bits of information that should be added to the story in order to further clarify things, as it happened with the example above (chugging down a heavy meal after a period of 18 hours without eating probably wouldn’t be a good idea).
As a User?
And please, if the “As a…” part of a story reads “As a user”, take a step back and think a little harder about that; user is too generic of a persona!
A User Story should convey the value its implementation brings to the business. Value may directly or indirectly relate to money figures. Happy users lead to value.
It should always be clear if a user story helps the business either make or save money. But what about non-profit organizations? Simply replace “make money” with “make someone happy” and “save money” with “save someone from pain”. That’s value. You got the idea.
User Stories are placeholders for conversations. These conversations must be centered around value (not technology or implementation) and it should be approached from different angles, until both stakeholders and development teams are clear on the value.
Improving is committed to sharing our knowledge and time freely with the technology community of Houston. We provide our stakeholders, be they consultants, clients, or members of the local tech community, opportunities to both learn and teach at locally hosted Classes, Training, User Groups, TechFridays, ‘Lunch and Learns,’ and now our Live Streaming Webinars.
If you have not had the chance to sit in on one of the Lunch and Learns given by an Improver, now is your chance. As we continue to find new ways to give back to the IT community and make it easier to access these insightful talks, we would love for you to attend and give us your feedback.
This event is open to everyone, and I hope you will join me in spreading the word to your community. You can register on EventBrite below with links for the live stream to come.
I hope to Virtually see you there!
I had seen Derek Sivers’ “Now” page a while ago (this is what that’s all about), and I finally decided to create my own Now page. So, now whenever anybody send me an email or text asking me “so, what have you been up to?”, I’ll point them to that page. Check it out: https://lassala.net/now/
I’m not sure yet how often I’ll update the page. At a very minimum, at least when I do my monthly review, at which point I check my current plans, which are derived from my previous year’s Annual Review. That’ll be a good way to make sure I’m still on track, and/or reflect upon course correction throughout the year.
I’m in Dallas to speak at the QA.Improving.us user group tonight, March 9, 6:30-8pm.
This has been my favorite talk in the last two years!
Testing in Agile: From Afterthought to an Integral Part
Testing cannot be an afterthought; it has to be an integral part of software development. Is it something that QA teams do? Or is it part of a developer’s duties? Do business analysts play any role in it? What is test automation? Unit test, Integration test, Test-Driven Development, Behavior-Driven Development… what do those mean?! This session addresses all of those questions, as we talk through the importance of tests, the collaboration among team members, the techniques, and practices around different kinds of automated testing.
I often hear something along the lines of “I cannot write tests for that UI code!” as the reason for the lack of unit tests. The fact is, more often than not, we can write tests for what seems to be “UI code”. I decided to come up with a talk to explore that topic and will be giving it at the Improving Code’s User Group next month, on March 4th.
In this talk, we’ll explore an approach to either write or refactor UI code so it can be tested more easily. We will NOT cover how to write automated UI tests, though.
Looking forward to it!!