I get really nervous about asking people for things. I hate confrontation, and I find it uncomfortable to ask for a favor or to try to persuade someone of my point of view.
It turns out, I’m not alone. Most people don’t like asking others for favors or trying to persuade them. But most of us also hate to say no. Which is great for those of us doing the asking, because it means people will cave in more often, since they just don’t want to turn us down.
But few of us know this about our fellow humans, so we tend to underestimate how willing people are to help us if we ask them to.
Several studies tested this by having participants first estimate how many people would agree before heading out to persuade strangers to do various things. The first example was a simple one: participants had to ask strangers to lend them their mobile phone. Participants estimated on average that they’d have to ask ten people before anyone said yes, but in reality they only had to ask an average of six people to get a yes.
Another study tested whether the size of the task would make a difference to how easily strangers could be persuaded to do it. Participants were tasked with asking strangers to fill out either a one-page or a ten-page survey. Amazingly, the odds for persuading strangers to participate remained the same across both tasks.
These researchers really wanted to learn about how to persuade strangers to do things. They did yet another study, this time making participants ask strangers to write the word “pickle” in a purported library book. In pen.
While many people expressed concerns about doing this task, participants were able to persuade over 64% of strangers they approached.
All these studies helped the researchers put together a theory that most people hate the awkwardness of turning someone down—even a stranger. A final study tested just how much people hate to say no by first having participants ask strangers to fill out a survey. For those participants who said no to this request, participants then asked them to take a letter from the participant and mail it.
Many people said yes to the request to mail a letter, even though it’s arguably a more inconvenient task than simply stopping to fill out a survey. These people, the researchers said, hated the awkwardness of saying no so much that rather than do it a second time, they preferred to take on a more inconvenient task than the one they’d already turned down.
Of course, not everyone is this averse to saying no. And, depending on the circumstances, most of us have situations where the awkwardness of saying no is not as bad as we feel agreeing would be.
But for those times when we’re on the fence, or willing to be persuaded from the “no” camp, let’s take a look at what you can keep in mind to encourage others to do things you suggest.
Persuading people to do things for you
I wouldn’t call these methods manipulation. In fact, I tried a couple of them on some local politicians recently, and was very disappointed in the results. So I hardly need to tell you to wield them wisely. These are very small adjustments, but they work, on average, by employing knowledge about what makes us rethink our own decisions and make different ones.
Use the word “willing” after you’ve met resistance
If someone has already said no, and you don’t want to give them a different task like mailing a letter, you may have more luck persuading them to do the original task with this approach. The word “willing,” it seems, is somewhat of a magic word when it comes to asking people to change their behavior.
One study asked people who’d been in an argument to try mediating the situation. Those who refused were then asked if they’d be willing to try mediating the situation.
As Psychologist Elizabeth Stokoe says, “if you ask someone ‘are you interested in mediation?’ they might say yes or no. But if you ask them if they’re willing to mediate, that requires them saying something about the type of person that they are.”
The difference, it seems, is that asking what someone is willing to do, rather than asking them directly to do something, changes that question about an immediate action to a question about what that person’s boundaries are. This makes them rethink their answer, as it brings their ideas about themselves as a person into the mix, rather than simply letting them make a quick decision about taking an action right now.
Stokoe warns, though, that this approach works best after meeting with resistance. So use this one as a backup when other approaches don’t work.
Use the phrase “you will probably refuse…”
Have you ever noticed how telling a kid to do something often makes them want to do the exact opposite? Or maybe you’ve even been this kid. You’re thinking about how you should clean your room when a parent walks in and gives you a roasting about how messy your room is, and tells you to clean it up. Well now that’s the last thing you’re going to do! There’s just something about being told we have to do something that makes us want to do the opposite.
Perhaps this comes from the fact that humans love to think we have a choice in everything. It doesn’t actually matter whether we do have a choice or not; we just need to feel like we do.
This approach taps into that mindset. When you start a request by saying, “You’ll probably refuse, but…” you tap into that person’s desire to prove you wrong. For instance, imagine someone raising money for charity stopped you on the street and said, “You’ll probably refuse, but would you like to help abandoned dogs with a donation?” Well, who among us wants to let a stranger be right about us not caring about abandoned dogs! Of course we want to prove them wrong by giving the dogs a donation.
One study tested this theory in a very similar situation. Researchers asked people to donate to charity in two different ways. Some people were asked directly, while others were asked like this:
You will probably refuse, but I wonder if you could help us by making a donation?“
While not everyone cared enough to prove the researchers wrong, the approach did work better than a direct ask for a donation. From those asked directly, 25% donated to the charity. From those told they would probably refuse, 39% donated.
It’s not 100%, but it’s certainly a bigger percentage, and it doesn’t take much effort to put this strategy into practice.
You might have used altercasting before without even realizing it. If you’ve ever suggested a friend, spouse, or colleague is particularly adept in an area before asking for a favor that relies on those exact skills, that’s altercasting. For instance, telling your spouse they’re a great cook before asking them to cook dinner. Or telling your friend that you always appreciate how generous they are, before asking for a loan.
Altercasting refers to casting that other person in a role. There are two ways altercasting can works. The first is called "manded” altercasting, which is what my examples are. This is when we don’t change our behavior at all, but we explicitly suggest a role for the other person.
The other method of altercasting is called “tact,” which is when we don’t explicitly suggest a role, but change our behavior to imply a role for the other person. For instance, if you make a mess and keep dropping things in an attempt to cook dinner until your spouse takes over, you’re implicitly suggesting the role of “good cook” for your spouse by showing how terrible you are in comparison.
The reason altercasting works is because we tend to want to live up to the labels we’re given. When someone we care about tells us we’re a good cook, or we’re generous, we feel the need to prove them right, because we want to see those traits in ourselves, too.
But this can prove dangerous when suggesting negative roles for others, such as telling someone they’re slow, unproductive, or lazy. It’s probably best to only suggest positive roles when using altercasting. Try suggesting a role you think the other person would want to see themselves in to avoid using this technique in a way that feels manipulative.
Whether it’s a local politician, your spouse, or a colleague, there are plenty of times when we want to persuade someone else to do what we’re suggesting. These methods certainly won’t guarantee that you can get others to do your bidding, but if you’re attempting to persuade someone, try throwing in one of these strategies to give yourself a better chance of success.
When you’re focusing on being more productive, producing better work, and motivating your team, it’s easy to forget to celebrate successes along the way. The small wins, in particular, tend to go unnoticed unless we make a conscious effort to savor them.
But research shows celebrating hard—and often—can actually improve your team’s performance and how well they work together.
Celebrating strengthens relationships
According to Shelly Gable, professor of psychology at the University of California at Santa Barbara, how you celebrate success is more predictive of the strength of a relationship than how you fight when things aren’t going well.
A 2012 study explains why the way you celebrate success is more important than how you handle tough times in a relationship. Looking at couples, the study found people whose spouses were supportive during good times believed they’d also be supportive when times were tough. The spouse didn’t even have to prove their support during rough periods; just thinking their spouse would be supportive in hard times was enough. Those relationships scored better for emotional intimacy, trust, and relationship satisfaction.
Celebration has also been shown to improve relationships among sports teammates. Research shows the more convincingly a sports team celebrates their success together, the better their chances are of winning.
A 2010 study looked at this effect specifically among basketball teams. The study found the teams who touched each other most with congratulatory taps, fist bumps, hugs, pats, and high-fives also co-operated the most and won the most.
Another study examined how celebratory behaviors in soccer teams correlated to which teams won more penalty shootouts. The study found that celebrations using both arms were most closely associated with winning shootouts. “It was more likely that the next kick taken by an opponent was missed after a player displayed these behaviours after a goal than when he did not,” say the researchers, who attribute this finding to something called emotional contagion. Basically, the player’s two-armed celebration is big enough to make the other players catch that enthusiasm. As a result, they all play better as a team.
So this is good news for everyone from friends and spouses to colleagues. Take some time to acknowledge good news among the team and celebrate success together—even making a big deal out of small wins could improve how well you work together.
Celebrating induces the progress principle
When it comes to productivity, it helps to feel good about your work. We all know how much easier it is to get things done when you’re excited by what you’re doing. Research shows that the best way to encourage these good feelings that lead to productivity is to make progress on meaningful work:
Of all the things that can boost emotions, motivation, and perceptions during a workday, the single most important is making progress in meaningful work.
According to studies, the more frequently people experience this feeling, the more productive they’ll be long-term. This is known as the progress principle.
And again, small wins can work just as well as big ones. Celebrating minor milestones throughout the day or week can be enough to make your team feel like they’re gaining momentum.
The only caveat to remember here is that the work must feel meaningful for the progress principle to work. So start by taking some time to help your team see how they’re contributing to meaningful results, and follow that up by ensuring you celebrate each other’s success.
While celebrating our success (and that of our teammates) can improve how we work together and how productive we are, it can also make us happier to share good news.
Research shows telling others about our own positive feelings can make us happier. But, even better, just thinking about telling someone your good news can make you feel happier, too.
Savoring is what social psychologist Fred Bryant calls the process of sharing and enjoying good news and positive feelings. It’s another way of talking about celebrating success or positive events. And Bryant says it’s something we should all be doing more of:
Savoring is the glue that bonds people together, and it is essential to prolonging relationships. People who savor together stay together.
Research also shows that when we outwardly express our good feelings, we tend to feel happier. This is because we’re giving the brain evidence that something good has happened. The brain can take in and respond to the external signs of good news when we express ourselves outwardly, which serves to compound our initial good feelings.
Although all this research points back to the basic idea that celebrating success—even small wins—is beneficial, there’s quite a bit to unpack within all that research.
For starters, simply sharing your good news or positive feelings with others can make you happier. That’s an easy one to get started on.
Before you start encouraging your team to celebrate more often, however, remember to make sure they feel their work is meaningful. We love the feeling of making progress, but not if we think our work is a drag in the first place. Show your teammates the fruits of their labor and help them understand how they’re contributing to something meaningful.
Once you’re all invested in what you’re doing, it’s time to turn up the celebrations. Encourage your teammates to share even small wins with each other, and make the time and effort to celebrate those wins as a team.
And remember, the bigger your celebrations, the better the effect.
When software crashes, you are increasingly likely to lose more than your high score in Tetris.
Our cars, our airplanes, and health care systems all rely more and more on software. As Marc Andreessen says, software is eating the world, as almost every industry is being reimagined with the impact of software.
All of this is to say that the quality of all this software is really important. Let’s dive into a landscape overview of quality in software.
When we’re talking about the quality of software, we’re talking about how good it is. Broadly speaking, there are two ways in which software is good.
The first is functional quality: “how well does this software do the job it’s supposed to do?” Will it crash if I try to import a CSV file? Can the user do the tasks that she wants to do with it without swearing and threatening the computer?
The second is structural quality:”how well is this software engineered?” Is it a pile of spaghetti code that will drive future developers to desperation? Or is it written in modular code that can be easily extended and modified later? Your users may not directly see the structural quality, but it still impacts how quickly you can develop new features and fix bugs that arise. You can sacrifice structural quality for speed, but doing this excessively will lead to technical debt.
Functional testing involves checking whether the software works as expected. For example, you might log into a microblogging app and try to create a post with no content and you expect to receive an error message saying that you can’t do that.
Every time you add some new code to your app, you run the risk of breaking the existing functionality (these are called regressions).
Ideally, you’d check whether the existing functionality still works after each new code change. That, however, will be very tedious if you’re doing it by hand.
That’s where the power of automation can come to your rescue. You can write a script that will automatically test the functionality you want to test. Here’s an example of a test for a Ruby on Rails microblogging app using the RSpec testing framework:
In the above screenshot, the test:
creates a user;
signs the user into the app using the Capybara web driver;
attempts to create a micro post with empty content; and
checks whether this results in an error.
The fundamental idea is that you can run this test repeatedly during your development process, and the test results will show you whether you’ve broken anything.
You can be sure that creating an empty post will result in an error message if this test passes.
This saves you from having to open up the app in your browser, logging in and clicking through all the screens to see whether you’ll get an error message if you create an empty post.
At the same time, you should still go through the app on a regular basis, thinking about whether the app meets the quality requirements you had in mind. However, you’ll be spared the boring task of checking whether every little piece of functionality still works for the 15th time.
The reason is that there is a subtle difference between checking whether everything works as you think it works and testing the product on whether it meets your required standard.
Checking is the process of checking whether everything works as you think it will work. For example, you introduce a new feature in your software, and you go back and check whether the rest of the software runs as intended.
“Checking”, Michael writes, “is focused on making sure the program doesn’t fail”.
The result of this is that you can write code that will test assertions about your code, and you can run those tests to see whether the assertions hold up or not.
In Michael’s definition, testing is an exploratory process in which you test the limits of the product at hand. Michael comments that when you are testing, you are “largely driven by questions that haven’t been answered or even asked before.”
You’re using your knowledge and experience to make judgment calls on whether something might be a problem. You can’t automate the process of exploring your software because by definition you’re uncovering new information.
You’re asking “what if?” questions about your software that you haven’t answered before.
The QA Function in Software Teams
Not every organization takes the same approach to quality in software. Some see it as a functional role owned by a team in the company. Others see it as a role in a cross-functional team, and yet others see quality as something every person working on the product should work towards.
Approach #1: the QA Team
Some organizations have a separate QA team that tests and analyzes the quality of the software. In this case, a developer develops a feature, and then it’s handed over to the QA team for assessment of its quality.
Perhaps the flaw in this approach is that you end up with a rather inflexible release schedule, an adversarial conflict between the product team and the QA team and perhaps even an attitude of developing features to the minimum required standard before letting the QA team figure out the problems.
Approach #2: the QA Champion
Some teams moved on to having a QA person in the cross-functional product team. That person would champion QA in the team and might also take the lead on writing automated tests. The aim is to move away from an adversarial situation where testers point out the problems in the developers’ work and move toward working together on producing higher quality software.
Approach #3: “No QA”
Finally, some teams have taken this approach a step further. They’ve adopted a “No QA” approach without any dedicated QA role in the team. Every developer owns the QA of their work. They write their own tests, think up of edge cases and ship features that meet quality standards. Steve Wells comments that having QA roles allows others on the team to abdicate responsibility for quality to someone else.
Some teams also advocate a “test-driven” approach to software development. In this model, you write the assertions the software should pass before you write the software itself. You then write the software to pass the tests and then you refactor the software (improve the code quality), all while keeping the test passing.
A Process for Tracking Issues in Quality
Regardless of how you approach quality in your software development process, you’ll need a process of tracking bugs or issues. Let’s work through a process using Planio, which is perfect for this use case.
Capture Information about the Bug
First, you create an issue in Planio reporting the bug. Joel Spolsky argues that a good bug report needs three things:
Steps to reproduce the bug;
What you expected to see; and
What you saw instead.
The reason for the second two is that it’s not always obvious that an outcome is a bug. The classic response to an irate middle manager filing a bug is, “That’s a feature, not a bug”. By being able to understand what the bug reporter expected to see you can determine whether the software is actually defective.
You might also want to gather information such as the browser, the operating system, the screen size or the device.
Prioritize the Bug
Is the padding off on one of your app screens? Or perhaps the security of your users’ data is at risk? One of these bugs is obviously more important than the other. You might even have a service level agreement that means you have to address certain categories of bugs within 24 hours, for example.
Communicate & Assign
Based on the priority, you’ll have to get one or more people to look into fixing it. This means you have to assign it to someone and you have to keep the reporter updated on the status of the bug. People hate submitting a bug, and never hearing another word, even if you fix it.
Reproduce The Bug
It’s hard to fix a problem you can’t see. Therefore, the first step toward fixing a bug will be to reproduce the bug. If the bug can’t be reproduced, you’ll have to assign it back to the reporter with the status Cannot Reproduce.
Review and Deploy
It is good practice to have at least one other pair of eyes look over a bug fix, as there’s no point in solving one bug to create two others. You’ll want to then assign the fix to someone else to review before deploying the bug fix.
You can set up custom statuses in Planio for bug tracking. For instance, they could be:
A bug can then cycle through these statuses, ending up at Fixed or Unresolved depending on the outcome.
That wraps up this article on quality in software. You should also check out these articles:
You probably know if you’re a night owl or a morning lark—or somewhere in-between. We all have an internal body clock that runs slightly differently, meaning we’re more alert and productive during a particular time of day, and prefer to sleep during a particular period. Night owls tend to have a later body clock, which makes them more productive later in the day and sleepy early in the morning.
If you know where your body clock fits, you can schedule your day to work with your energy levels rather than against them. Depending on how much flexibility you have, you might be able to schedule your entire work day to be a few hours earlier or later than your colleagues to suit your body clock, or you may just have to juggle your 9-5 hours so your most important tasks are scheduled for the hours you’re most switched-on.
Despite having a period of time when we’re most likely to be productive, we also have an unfortunate tendency to self-sabotage during those same hours, according to research.
Self-sabotaging is when we set ourselves up for failure so we don’t have to face the truth about whether we would have failed otherwise. A good example is having a huge night out before an important meeting, or when we spend the night partying instead of studying right before an exam.
By sabotaging our own efforts, we have an excuse to fall back on when we fail, which protects our egos from taking the fall.
One study found that “you are more likely to engage in self-sabotage during the hours in which your mind is at its best.” The study’s lead author, Julie Eyink, says, “unfortunately, it’s not uncommon to get caught in a negative spiral, in which self-handicapping leads to lower self-esteem and higher failure beliefs, which prompt more self-handicapping.”
And it’s not just the obvious acts of staying up late, not preparing for a meeting, or getting drunk so you head to work with a hangover—self-handicappers also tend to make-up excuses for not being able to perform like being sick, tired, or stressed.
This might sound like procrastination in the extreme, but it’s slightly different. While we procrastinate to avoid all kinds of unpleasant emotions, such as boredom, stress, or frustration, self-sabotage is mostly related to a fear of failure. Ed Hirt, another author of the study explains:
People who are feeling uncertain about themselves and start to fear that they might fail are more likely to identify potential excuses and self-handicap when they’re at their peak than when they’re not.
So these destructive behaviors tend to start from that one nasty feeling: a fear of failure. Stopping ourselves from self-sabotaging is difficult, because we often don’t realize exactly why we’re doing it. We know we should be preparing for work, but we find ourselves at the bar anyway, and we can’t really explain it.
If we focus on that fear of failure instead, we may be able to lessen the fear that’s causing us to self-sabotage in the first place.
Think of failure as a learning experience
Jeff Atwood, founder of Stack Exchange and Discourse, says developers should learn to expect failure. After all, it’s extremely common when dealing with software projects.
As a developer, the likelihood that you’re working on a project that will fail is high. Every failure should be considered a rich opportunity for learning what doesn’t work, and why.
Atwood isn’t fetishizing failure, as we’ve seen happen in startup culture, but rather pushing us to accept that it’s likely we’ll run into failure. Since failure is common for software projects, setting out with the idea that failed projects can teach us something can take the sting out of failure when it does happen, and help us get past our fear of it.
“If you really want to know if someone is competent at their profession,” says Atwood, “ask them about their failures.”
He quotes an article by Malcolm Gladwell about predicting the success or failure of surgeons. In the article, sociologist Charles Bosk explains that when interviewing young doctors who’d been fired or resigned to determine what had made them fail, it was those who said they never failed who didn’t fit his prediction of who would become a good doctor.
And the residents who said, ‘I make mistakes all the time. There was this horrible thing that happened just yesterday and here’s what it was.’ They were the best. They had the ability to rethink everything that they’d done and imagine how they might have done it differently.
Michael Hunter from Microsoft says, “learning doesn’t happen from failure itself but rather from analyzing the failure, making a change, and then trying again.”
If we’re to learn, we need to fail—but more than that, if Hunter’s to be believed, we need to thoroughly analyze those failures to understand how to avoid that failure next time.
Think of yourself as a scientist
Buckminster Fuller was an eccentric and prolific inventor. He published over 30 books as well as inventing various architectural designs, and even coining new terms such as “Spaceship Earth.”
But one of the most interesting things about Fuller is his scientific approach to life. After hitting rock bottom and considering suicide, Fuller decided to instead approach his life as an experiment. Since he had nothing left to lose, he began thinking of his life as one long study in how he could best contribute to humanity. “My objective,” he said, “was humanity’s comprehensive success in the universe.”
Fuller’s approach to life made it possible for him to fail, often, and invent things that didn’t work, without losing enthusiasm for his work. His thought process reframed failures so they simply became data points in his life-long search for the best ways to contribute to the human race.
As designer and entrepreneur Paul Jarvis says, this style of thinking makes it easier to try things that might fail. Jarvis noticed his skills stagnating and knew side projects could help him improve, but fear held him back. “My day-job was comfortable,” he says, “so I didn’t want to fail at something new.”
Side projects can be scary. There’s more of us in them so they hit closer to home. This can make them difficult to start or follow through on.
Jarvis realized thinking like a scientist would stop his fear of failure from holding him back.
To get over my own fear of failure with them, I started picturing these ideas as simply being experiments. Experiments don’t “fail"—they simply prove or disprove a hypothesis. For example, despite my day job as a designer I had the hypothesis that I could also write an e-book. I then simply started writing. I didn’t focus on the outcome, how the book would be received or what others would think of it. I figured, "let’s give this a try”.
Jarvis readily admits that many of his side projects have failed. “Some only proved that there wasn’t a market or opportunity for an idea, and several apps I made didn’t sell a single copy,” he says.
But his new approach to thinking about side projects has removed the fear that leads us to self-sabotage. Now Jarvis is experimenting constantly, rather than finding excuses to stay safe.
Remember that failure is necessary for success
Another entrepreneur who knows a thing or two about failure is Scott Adams, creator of Dilbert. Adams has had many an entrepreneurial idea in his time, and many have failed. In fact, Adams admits Dilbert was one of his many schemes to make something people wanted, rather than a passion project, and it just happened to take off.
“For most people,” he says, “it’s easy to be passionate about things that are working out, and that distorts our impression of the importance of passion.” Cartooning wasn’t something Adams was passionate about when he started Dilbert, but he says his passion mysteriously grew as Dilbert’s success increased.
So Adams suggests we don’t rely on passion, but rather focus on figuring out what people want, and using failures as stepping stones along the way.
… failure is where success likes to hide in plain sight. Everything you want out of life is in that huge, bubbling vat of failure. The trick is to get the good stuff out.
More than just accepting that we’ll have failures and we can learn from them, Adams takes things a step further. Failures are the best learning tools we have, insists Adams, and they should be doing more than simply preparing you for future failures.
If I find a cow turd on my front steps, I’m not satisfied knowing that I’ll be mentally prepared to find some future cow turd. I want to shovel that turd onto my garden and hope the cow returns every week so I never have to buy fertilizer again.
According to Adams, failures are necessary for us to reach success. So besides accepting them when they happen, we can prepare ourselves for failures that might arise by remembering that any failure is a step closer to success.
Fear of failure is a tricky subject, because many of us don’t realize we have it in the first place. But if it’s holding us back by causing us to self-sabotage during our most productive hours, it’s something we need to get under control.
Fear is a strong feeling to overcome, but combining an experimental approach to our work, acceptance that failure is necessary for us to reach success, and looking for ways to learn from each flop we produce can take the sting out of failure so we’re a little less hesitant to face it next time.
This is a guest post from Alexander Lemm, Manager Global Consulting Portfolio at Software AG.
We are a happy Planio customer using a customized Enterprise Planio instance since 2010. Initially, our consulting division used it to collaborate with our own customers in projects. Soon, other departments like Sales and R&D discovered it and leveraged the platform for their own purposes as well. At this point in time our Planio instance has approximately 2800 active users and 3000 active projects.
Planio provides excellent agile project management support via the agile module such as the sprint planning board, the task board and various agile charts.
In this article we will highlight some of the best practices we have derived and applied at Software AG in our agile projects using Planio. We will focus on setting up our project, user stories, tasks, boards, and communication in general.
First, we start by adding our sprints in the settings module. Here we can add our desired number of sprints, the starting date of the sprint, and perhaps a duration or the sprint goal in the description.
We can also add categories within the settings module, which will appear as a drop down menu on all our issues. You can define categories per your project needs, but they should give the sprint team an idea of the kind of work that the task involves.
User Stories are high level features described using a non-technical language which can be explained easily to customers. Each user story encapsulates several technical sub-tasks. However, those sub-tasks are not used when communicating with the customer. They are only of interest to the development team and added to the user story during a sprint planning meeting one or two days before a sprint starts.
Typically, a user story consists of 3 parts: the title, the description and the acceptance criteria:
It is a no-brainer to see that at least the title and the description of a user story can be encapsulated in an issue. We use a dedicated tracker named Feature Request to represent user stories in our Planio instance. It is not called “user story” because the agile module was added a couple of years after our initial Planio launch and we didn’t want to add an additional tracker.
But what about the acceptance criteria? For this we use checklists, which are an optional but integral part of an issue. Each acceptance criteria is added as a separate line item to the check list. In this way, all 3 major parts of an user story are included in a single issue.
But what makes check lists even better?
During sprint review meetings the customer or product owner himself, who is usually a project member, ticks off the acceptance criteria in the check list.
We found that the direct participation of the customer in this process had a positive impact on the development team’s motivation. Additionally, dev team members who can’t participate in the sprint review meeting can see the customer’s accepted test criteria just by looking at the issue’s history the next day.
A task is a technical piece of work necessary to get a user story done. As such, it makes the most sense to represent tasks as sub-issues in Planio that are associated with the respective (parent) user story. We use a specific tracker type for this, which is also called “task”.
We see very little value in tasking out user stories that won’t be part of the next iteration. Therefore, we always elaborate tasks in sprint planning sessions directly before the next iteration. The development team itself defines the tasks.
The User Story Lifecycle
All user stories initially appear with a ‘New’ status without a sprint assigned; this is our Product Backlog. During sprint planning we decide which backlog items we will take into sprint, and the respective sprint is assigned to the user story. From here we start progress on the sub-tasks which were added to the user story until we believe all criteria as per the checklist on the user story have been met. We are then ready for acceptance.
If necessary, a feature request can be moved back from “Closed” to “In Progress”.
The Task Lifecycle
The task status should reflect its progress within the sprint. When we see a status change, it’s because progress has been made on the task. When this happens, we can also see the Assignee change; predominantly from a developer to a tester.
As the task is completed, this in turn updates the progress of parent task, which in our case is the user story, as mentioned above earlier.
Another handy feature in Planio is the Agile Board which mimics the classic Scrum board. A project can have many agile boards which are configured in the same fashion as issue reports using the filter settings.
In general, we work with three different types of agile boards:
User Story Board: This board only shows the user stories and their current status. It is the main board when having sprint review meetings or discussions with the customer.
Sprint Board: This board shows all technical sub-tasks that the development team has assigned to the current sprint. It is the main tool for the team when having daily scrum meetings.
General To-Dos: Of course, each project includes tasks which are not directly associated with a sprint; for instance, ideas discussed and identified in retrospectives. All of those sprint-independent to-dos are tracked using the General To-Dos board.
We often collaborate in virtual teams including members of our offshore centers in Eastern Europe and Asia. Therefore, communication is absolutely key for us.
Experience has showed that email should not be used as the primary communication method in those setups because the risk of missing important requirements clarification or design decisions is far too high. All communication must be conducted through a central collaboration site, which in this case is the Planio project itself.
One Planio feature which was underrated, or at least overseen for many years in our company, proved to have a big impact on communication and thus project success: the blog module.
When working in virtual teams that include multiple nationalities the daily scrum meetings usually take longer than 10-15 minutes. On average, we spend approximately 30-40 minutes on them using web conferencing to create a sense of proximity between team members. Summarizing and publishing the minutes of the most important findings and topics of the daily scrum meetings proved to be of high value. When questions come up, the customer, who also receives an email containing the blog post, can directly jump in and clarify open issues raised by the dev team by leaving a comment underneath the article.
In addition, the minutes of sprint review meetings and retrospectives are also distributed and discussed that way. Similar to the checklist effect discussed above, we found that the direct involvement of the customer had a positive effect on the team: everyone was much more engaged and pleased when working on the project.
Also project onboarding gets much easier when using this communication style. A new team member simply needs to read the last blog posts in order to be up-to-date quickly. In addition, the most important project communication is preserved in the project itself and easily searchable if necessary.
That wraps up our overview of how we implement scrum using Planio. I hope that you enjoyed the read and that our agile best practices will be useful for your projects as well.
We spend a considerable amount of our lives looking forward to our spare time. We watch the clock during the workday, we count down the days until our next holiday, we look forward to Friday nights and dread Monday mornings.
But despite our yearning for free time, we also tend to waste it once it comes around. At least, we do according to Mihaly Csikszentmihalyi, author of Flow.
Csikszentmihalyi’s book explores the state of flow—when you’re so involved in what you’re doing that time flies by without you realizing. It’s something we all want to find in our work, but Csikszentmihalyi says we should be looking for it in our free time, too. In fact, he says flow is the secret key to enjoyment.
Finding flow in your spare time
The problem with how we spend our spare time, according to Csikszentmihalyi, is that we’re not naturally drawn to activities that produce a flow state. We tend to opt for passive activities like watching TV.
A flow state, on the other hand, comes from periods of deep concentration when you’re using skills. We don’t get much satisfaction from watching TV all day, but improving your skills or making something from nothing produces a sense of accomplishment as well as being a ripe opportunity for that elusive flow state.
Csikszentmihalyi says many people feel alienated from their work, and resent the energy they put into a job they don’t care about. But then those same people waste their free time as well:
Leisure provides a relaxing respite from work, but it generally consists of passively absorbing information, without using any skills or exploring new opportunities for action. As a result life passes in a sequence of boring and anxious experiences over which a person has little control.
In his research, Csikszentmihalyi found people tended to be happiest in their free time when they were “just talking to one another, when they gardened, knitted, or were involved in a hobby.”
More free time won’t make you happier
Regardless of how we spend our free time, we tend to think if had more of it, we’d be happier. Even just an extra day off now and then would be nice, right?
The strange thing is, research shows taking extra time off won’t necessarily make us happier. A study into how we spend our time found that most people’s moods fluctuate as you might imagine: we’re happier on Friday, Saturday, and Sunday, and have our worst moods during the workweek.
But the strange part of the study was that people without jobs reported pretty much the same fluctuations in mood as those who did work during the week.
Researchers believe this is because free time is an example of what’s called a “network good.” Network goods are things that derive their benefits from being shared. In this case, free time is only valuable when it’s shared.
A follow-up study looked at when people spend time with friends and family, and found this pattern mimicked the fluctuations in mood from the previous study. Social time roughly doubled on the weekend, and accounted for about half the improvement in mood for study participants.
Again, this was consistent with participants who didn’t work during the week. Just because they had free time while others worked didn’t actually make them happier—they were missing “together time” as much as the workers were.
With more flexible work schedules becoming more common, we may have to put in more effort to coordinate our schedules with others. But this research suggests the benefits would be worth putting in that effort.
Give and you shall (think you) receive
This is counterintuitive, but research shows when we feel like we’ve done a lot with our time, we also tend to think we have more time overall. And one great way to feel like you’ve used your time well is to give that time to others.
A series of studies looked at the differences in how much time we think we have based on giving our time to others, wasting it, or spending it on ourselves. In each study, the participants who spent their time on others felt they had more time at their disposal than either of the other groups.
The participants who gave their time were also more likely to do more work on follow-up tasks than those who wasted their time or spent it on themselves.
One of the studies didn’t require the participants to give or waste their time during the study, but simply asked them to describe a recent time when they had done something outside their normal responsibilities—either for themselves or for someone else. Again, those who remembered helping others felt they had more time to spare in the future.
The sad part is that we tend to prioritize our time to spend on ourselves and our own responsibilities when we feel we’re time-starved. If we spent extra time helping others, however, we’d be more likely to feel like we had plenty of time to get everything done.
Find a hobby, sport, or skill you enjoy, and work on it in your free time.
Not all your free time needs to be spent avoiding TV or other passive hobbies. But try to find (or schedule, if necessary) time to work on something you’re good at, and want to get better at. You’ll be more likely to feel satisfied and accomplished after spending your time this way.
Plan your time off to coincide with friends and family.
Whenever possible, try to take off the same days as your friends or family to get the most enjoyment out of your free time. If you’re planning to have extra time off—unless you specifically need some alone time—try to match it up with others to get the biggest benefit.
Spend more time helping others, especially when you’re time-poor.
It might be difficult to put this into practice, because it’s so counterintuitive. But if you want to feel like you have more time in your life, spend just 15 or 30 minutes doing something for someone else.
She’s a back-end developer at a startup revolutionizing the pet industry by creating robot dog sitters for the highflying pet owner.
It’s exciting stuff that has the potential to endlessly entertain pets everywhere.
A quick recap of her day: Pam walks into her open-plan office, sits down in a room full of other people, put on her pair of noise-cancelling headphones and tries to focus on a hard problem.
Then, the person besides her starts cracking up at a video a colleague sent via team chat. And then Palm gets a chat notification herself. And while she’s looking at notifications, she decides to hit up her email inbox.
Boom. She’s sucked into a vortex of urgent and not important tasks clamoring for her attention.
The machine learning algorithms for the robotic dog sitters? Not much happens on that for today.
The Role of Focus in the Knowledge Economy
The knowledge economy is based on organizations taking intellectual knowledge and turning that knowledge into business value.
In the book Deep Work, Cal Newport posits that there are two core abilities for thriving in this economy:
the ability to master hard things;
the ability to produce at an elite level, in terms of both quality and speed.
Following Newport’s thesis, learning to master the filters in SnapChat is both easy and not very valuable in the modern economy. On the other hand, the ability to analyze large sets of data (perhaps which SnapChat filters are the most successful) is both very difficult and very valuable.
Secondly, Newport argues that to produce at your peak level, you need to be able to work for long stretches of time with absolute concentration without being interrupted.
On the question of why focus is so important, Newport suggests that the answer may lie in a fundamental process in our brain. He refers to The Talent Code by Daniel Coyle. In the book, Coyle makes the case that myelin, a layer of fatty tissue that develops around neurons, acts an insulator that permits cells to fire faster and cleaner.
When you’re trying to acquire a complex new skill while simultaneously flicking around on SnapChat, you’re firing too many circuits haphazardly to isolate the group of neurons you want to strengthen with myelin.
Therefore, both Coyle and Newport favor a single-minded focus, rather than multi-tasking, for both skill acquisition and performance.
Why Do We Find It So Hard to Find Focus?
Once we take the view that focused single tasking is vital for succeeding at knowledge work, the question then shifts to how we go about doing just that.
Undoubtedly, the tech industry’s fascination with open-plan offices hasn’t helped. The idea that sitting in a sea of other people chatting, phoning, giggling and what have you are all conducive to focus is, well, unusual.
However, we can’t just lay all the blame on open-space offices. Anyone who’s tried to work from home can attest to the difficulties they’ve faced in finding focus even when alone.
Newport argues that a big part of the reason why we spend so much time in meetings, emails and chat is that, in absence of clear feedback on the impact of various behaviors on the bottom line, we’ll tend towards behaviors that are the easiest in the moment.
And meetings, emails and chat are often easier than the actual work.
A slightly more nuanced view comes for the authors of “The Four Disciplines of Execution” (4DX). They point towards the “Whirlwind” as the reason we fail to focus on our most important work. The Whirlwind is the mass of day-to-day events that require our focus. It’s the sudden emergencies, the server outages or the angry customers. It’s the work that needs to be done to keep the show on the road.
It’s important work. It needs to be done, but it’s also not the work that will bring the organization to the next level.
The 4DX authors argue that these ongoing demands have to be balanced with strategic goals if you want to grow and move forward.
The 4DX Framework for Finding Focus
I found the solution laid out by the 4DX book to be so interesting that I’ll give you an outline of the strategy. In many respects you’ll find traces of many agile methodologies in it.
Focus on Wildly Important Goals
There’s a story of Warren Buffet advising his personal pilot, Mike Flint, on career goals.
Buffet told the pilot to write down a list of his top 25 career goals, which the pilot did.
Then Buffet told the pilot to circle his top 5 goals, which the pilot also did.
Buffet asked the pilot how he’s approach the goals. The pilot said he would mainly work on the top 5 goals and occasionally focus on the other 20.
Buffet replied angrily:
Everything you didn’t circle just became your ‘avoid at all cost list.’ No matter what, these things get no attention from you until you’ve succeeded with your top 5.
In the same vein, the 4DX authors advise focusing on the “one or two goals that will make all the difference, instead of giving mediocre effort to dozens of goals”.
Act on Lead Measures
You probably have some metrics for monitoring how well you’re doing - revenue, user growth or last sprint’s performance.
The problem with these metrics is that they’re telling you how well you’ve done in the past. Once you know the, it’s too late to change them.
They’re lagging measures of performance. Focusing on them can be demoralizing, because you can’t change last month’s numbers by doing something today.
At best, you can do something today to change next month’s numbers. And that’s where lead measures come in.
At lead measure is a metric that is within your control that will predictively impact the lagging indicators.
Here are a few examples of lagging measures with corresponding lead measures:
increase revenue -> make an upsell offer to every customer you talk to each day;
increase inbound leads -> write 500 words per day;
get more clients -> send at least 50 emails per week to potential customers;
find a new job -> ask one development hiring manager out for a coffee per week;
learn to code -> make one Git commit per day.
The beauty of having a lead measure is that you have something very specific that you can focus on: “Did I hit my lead measure today or not?”
And this brings us very nicely to the third principle.
Keep a Compelling Scoreboard
The 4DX authors tell the story of a football team playing an important game in front of a large crowd just after Hurricane Katrina.
There was a twist to the game, however. Hurricane Katrina had blown away the scoreboard, so the spectators couldn’t follow the score.
Instead of the usual chants and cheers, there was a low hum of bored conversations drifting from the audience.
Without a scoreboard to keep track, the spectators lost all interest in the game.
In the same way, once you’ve selected your wildly important goals and settled on your lead measures, you also need to a way to keep track of progress.
Cal Newport kept a running tab of hours spent working deeply on a book as well as the milestones of the book, such as completing chapters of it, on a piece of paper at his desk. He’d simply make a mark on a piece of paper for each of deep work he did.
That’s a great duo of both lead and lagging measures kept in a place he’d see daily.
Keep a Cadence of Accountability
The 4DX authors comment that you need a “rhythm of regular and frequent meetings of any team that owns a wildly important goal”. During the meetings, each team member states the specific actions they’re going to take in the following week to hit the lead measures, acknowledge the current state of the scoreboard and give an account of what happened regarding the previous week’s commitments.
Find the System that Works for You
You know, it’s hard to do hard work.
It’s rare that someone comes into the office after a long weekend, and, when asked what they did, say:
You know, I didn’t really have much planned, so I ended up sitting around on the couch, and before you know it I ended up shipping a side project I had lying around. I really must watch out to stop being so damned productive.
If you’re looking for tactical approaches for applying these principles, you can check out our article on the pro and cons of 6 different productivity systems.
Earlier this year we were talking about integrating Planio with Atlassian products with the partnership team at Atlassian.
The driver behind the discussion was to open up our respective ecosystems, so you can pick and choose what you want to use. For example, you could host your Git repositories at Bitbucket and track issues and manage your project in Planio. Ideally, you’d be able to jump from Planio issues to Git commits in Bitbucket as easily as you can to Git commits in Planio.
Now, it’s never easy to find time for new projects when you’re a small, bootstrapped team.
But, Atlassian invited us to join their Connect Week in March in Amsterdam. As Amsterdam is practically around the corner from Berlin, we couldn’t say no. So, we headed down for a week to hang out at the amazing Room Mate Aitana Hotel in Amsterdam, drink excellent coffee and hack away on the integration.
In a bare week, Holger and Jan managed to have a fully functioning demo to present on Friday thanks to the power of focusing on a project for a weekly long hackathon.
Sidenote: Taking a week out away from the office to work on one project can do wonders for your team’s productivity.
We didn’t stop at just this first version of the integration, however.
After talking with the integration team at Bitbucket, they suggested that we work on integrating the Agile board from Planio right into Bitbucket.
As it happened, the second Atlassian Connect Week was coming up in August in San Diego. This time it wasn’t just around the corner, so we couldn’t make it in person.
However, we joined in the fun virtually from Berlin. We hooked up to a HipChat room so we could keep up with all the action at the Connect Week.
And when it came to demo day, Jan created a quick video to showcase the new updated Bitbucket integration, so we could present it to the rest of the Connect Week attendees:
Here’s a view of how that Bitbucket and Planio look like together now:
So, there you have it! You can have the Planio Agile board right in Bitbucket. You can update issues, comment on issues and create new issues without leaving Bitbucket.
And that’s on top of the existing integration that lets you connection Bitbucket repositories to Planio, so you’ll be able to reference Bitbucket commits in Planio issues and Planio issues in Bitbucket commits.
This is a guest post from Userlike, which lets you add live chat to your website or app. We use (and recommend) Userlike ourselves at Planio.
So you’ve got your project plan set up. Now it’s just down to the execution. Easy, right?
Actually, that’s where many of us go astray. We look back at the end of the day and wonder what went wrong. With project planning you’re dealing with the macro level, while the daily execution covers the micro. But the micro is a real challenge.
The internet offers a world of distractions at our fingertips, making it ever harder for us to focus on the execution, to reach that state of ‘flow’ that makes highly productive hours fly by.
I’m convinced that 90% of us start out the day with best intentions. But few of us reach them.
At Userlike, we’re a bit obsessed over productivity. We’re a small software company going toe to toe with the giants in the industry. The only way to win is to stay laser-focused.
These are our tactics for having mightily productive workdays.
1. Clean Desks
What’s the opposite of focus? Distraction. Getting rid of all possible distractions enhances your chances of maintaining a structured workday.
Consciously or not, your brain processes everything you see – which can trigger a flow of thought followed by a disruptive action. Imagine having these items on your desk:
Sunglasses. “Will it be sunny today? I should go to the beach this weekend. But I don’t have swimwear. I should buy some. Let’s look at Amazon quickly.”
Wallet.“Do I have enough cash on me for lunch? What am I having for lunch? Is there an ATM nearby? Better check Yelp and Maps.”
Smartphone. “No message yet. Why isn’t s/he calling? Was it something I said? Let’s check Facebook, see what s/he’s doing.”
When your task is all that’s within your vision, you minimize the odds of getting sidetracked. That extends from your desk to your desktop and browser. By creating dedicated browser identities for your work activities on the one hand, for your private activities on the other, for example, you ensure that your vision catches only what’s relevant.
Keep things clean and organized, your mind will follow.
2. Day Planning
Sometimes we have an urgent task awaiting us at the start of our day. It’s tempting to just dive into it. But while that might get that task done fast, you risk the rest of your day culminating into chaos.
Starting off your day without a plan is like starting a roadtrip without a map; you’re bound to get lost. Except that an aimless road trip can still be a lot of fun, while a similar work experience is mainly stressful.
In our team, we write down our three Most Important Tasks (MIT’s) at the start of the day, ordered by priority. We focus on completing these first, after which we can focus on to-do’s that are less urgent, less important, or that require less brainpower. We share these goals in our #goals Slack channel for the sake of accountability.
One benefit of arranging your daily to-do’s with a list is that you don’t need to think about what’s next after a task or distraction – you just take a quick glance at what’s next.
3. Time-Task Goals
Estimating the time it takes to complete a task is challenging. Firstly, because we all suffer from the planning fallacy – the tendency to underestimate the time, cost, risk, and effort of future projects. Secondly, it’s simply easy to get distracted. Not only by BoredPanda posts, also by work-related issues.
A simple trick to counter this fallacy is to set time goals for yourself for the task at hand. It is my goal to have the first draft of this post finished by 2PM, for example. I estimate this based on previous posts I’ve written.
Don’t panic if you break your goal. Analyze what went wrong (did you get distracted or was your planning unrealistic?), and set up a next goal. You’ll improve in estimating accurate time spans for your tasks.
4. To-Don’t Lists
You are probably very well aware of your own weaknesses when it comes to distractions. Some succumb to Facebook, others to Twitter, 9GAG (that’s me!), or Bored Panda.
To defeat your procrastination outlets, create a to-don’t list at the start of your day. Do it on paper, if possible, and keep it as a reminder next to your workstation. In his book Influence, psychologist Robert Cialdini explains how the act of writing down an intention on paper increases one’s commitment.
5. Notification Kill
Every app on your mobile device asks you to enable notifications. Before you know it, you’re receiving a never-ending stream of notifications, relentless focus disrupters.
Be the boss of your communication channels. You decide when you check for notifications, not them. That counts for procrastination apps like Tinder, but also for business apps like Slack. Every beep or blink will be a minor disruption. They add up to wreck your workday.
People will call you if it’s an emergency. Honestly, how urgent was the most urgent message you’ve received through text? For me they’ve only arrived when people couldn’t reach me on my phone. Keep your phone on and you should be fine.
6. App-date Checking Slots
Of course you don’t want to miss out on all the events passing by in your apps. That’s ok, it’s just that you don’t need to be notified of them right away.
Schedule for yourself two or three update checking slots per day, during which you go through your app-dates. 9 a.m., lunchtime, and the end of your workday, for example.
7. Urge Tracking
Throughout your day, you will feel the urge to break your commitment – to check your WhatsApp, to visit 9GAG, or to check for a rare Pokemon in the area. That’s natural.
A powerful trick to stay committed, originating from meditation practices, is to physically take note of those urges with a pen and paper. Don’t bend to them, but don’t ignore them either. Simple note down a ‘I’ on paper whenever one arises.
8. Good Idea Notes
Ideas are great, but they can also hurt your flow. Truly good ideas stick and come bouncing back, so making a mental note of them won’t suffice. Instead, keep a notebook for those ideas, so you can get back to them at a later point in time.
9. Three Hours of Peace
Having a hard time ignoring those messaging beeps? Try ignoring your colleague standing at your desk with a question.
Communication is key to success in any business, of course, but so is respecting each other’s workflow. Get the best of both worlds by formalizing a few hours of 'quiet time’ every day. We do 9.30AM until lunch (12.30PM). This offers enough time to discuss some quick issues before, after which we can enter the flow.
You’ll be amazed how much you can achieve in just a few hours of peace.
If you want to be mightily productive, it’s time to start considering your brains as set of peculiar muscles. Like a muscle, your mental willpower tires throughout the day.
To manage your mental energy efficiently, remove as much friction in your workflow as possible. One thing that works especially well for heavy internet users is to set up a tightly organized bookmark system.
Bookmark all websites that you use frequently, and organize them in a clear and logical order. Don’t waste mental energy on recalling that URL.
11. Water, Healthy Snacks, and Movement
Now this post isn’t for a lifestyle magazine. But like a muscle, your brain needs fuel. And it has 3 fuels: liquids, food, and oxygen.
Keep a bottle of liquid on your desk to stay fresh throughout the day. None of those sweet drinks, they’ll throw up your energy levels before dropping them down on a knee like Bane did to Batman. Just stick to water or tea.
Hungriness or a low sugar level will kill your focus. Choose a healthy snack that can keep you going throughout the day. Nuts are my favorite.
And finally, get up once a while. Not only is sitting the new smoking when it comes to health, overly long sitting sessions also hurt your ability to focus. The circulation of blood and oxygen goes down, numbing your mental abilities. Consider a standing desk, or use a reminder app like Stand Up!
I hope this list will assist you in reaching new heights of productivity. Go with the flow!
Pascal is Mr. Marketing at Userlike. Besides leading Userlike’s marketing plan for world domination, he fills his days watching old movies.
Planio users asked us if we had a page where they could see the latest updates to Planio.
And we realized that we didn’t have a good outline of Planio updates.
The thing about a software-as-a-service product is that you’re constantly improving the product. But when you’re in the midst of building it, it’s often hard to see exactly what’s changed over the last couple of months and years, because you don’t have a big roll out of new versions as in the case of software you install.
We were starting to feel like were treading water. We were always shipping, and yet we didn’t feel like we’d accomplished much.
But when we had a look back at the improvements made to Planio over the last year, we realized that we’d accomplished a lot.
So, we decided to start writing a release blog using the blogging function built into Planio.
We started back in March 2016. Since then, we’ve added 21 new features, updates and improvements.
As a team, it’s very motivating to look back on all these different improvements. It makes us want to ship even more new improvements!
Recently, we rolled out two big new changes that we’d like to share with you.
The first is that Planio is now running on Rails 4 and Redmine 3. This means that we’re now officially on the same major version as upstream Redmine. As a result, we can now develop new features faster while staying in sync with open source Redmine.
Planio users will get improvements faster, and we’ll be able to share them with the open source community more easily, so we’re very excited about it.
The second update is a smaller change that we feel will have a big impact.
We’ve added HTTPS access to Git repositories in Planio using your Planio username and password, and we’ve also added anonymous Git access to Planio.
This means that you can now make your hosted Git repositories publicly available for anyone to clone – which is great for Open Source projects.