The Best Way For Efficient Communication

In IT as well as other areas communication or the conveyance of information is an important factor. As you might have experienced yourself, communication in general is an error-prone thing. Misunderstandings and perceptions occur regularly and have an impact. Wrongly understood information could lead to unnecessary costs for your organization and frustration amongst staff.

Communication that is not efficient is costly itself and leads to further cost since it necessitates additional communication and in worst case even redoing work. For communication to be truly efficient it is essential that all communication channels are used, such as body language, face expression and tone.

Humans have always had different ways of communicating, the advent of information technology has radically increased our options. From text messages with limited words up to video conferencing everything is possible …assuming smoke signs are not relevant anymore 🙂

Each way of communicating brings advantages and also disadvantages and should be used according to purpose. For creating and appointment with friends a short text or call is sufficient. When you discuss technical requirements in details, video conferencing might be the first choice. Everything could be recorded and you can watch it again or use the video for knowledge transfer. Even body language and face expressions are captured to a certain extent.

Amongst all ways and tools of communication, which one is the most efficient when it comes to business communication? In reality, communication is mostly done just like that without taking the time to choose the proper method, tool or environment for it. It could be way more efficient if you consciously think about communication and set up your communication channels accordingly.

Face to face conversation is the most direct and most efficient way to communicate. It is the most efficient way when it comes to gathering full understanding of what the other person has to say. In a face to face conversation you can ask questions directly. This would also be possible via telephone or instant messaging conversation. What you will not get by using any other method of communication is the mood, face expressions and body language. Video conferencing might allow this in part but won’t be as effective as a direct face to face conversation.

As mentioned above, there are tools that support direct communication as well. These tool still have drawbacks that you won’t find in a face to face conversation. Tools depend on an infrastructure, which needs to work properly, tools need to be operated and maintained. Tools might deliver low quality transfer of information that makes it difficult to see or hear the other person properly. Tools don’t transfer non verbal language, such as body language, face expressions or moods in the same way face to face communication does.

Especially in the context of software development, where a lot of clarification and communication happens between involved people, it makes a difference whether conversations are effective and efficient or not. With direct face to face conversation there are less filters and transformation involved than with any other way of communication. With that the risk of misunderstanding goes down enormously.

An impediment is when people are spread over several geographical locations. Co-locating people that work together should always be preferred. Even in the case where several geographical locations are involved in your software development project you should arrange working together at least for the initial phase, so that people get to know each other personally. If possible let people come to work together regularly.

A lack of motivation to talk face to face results in time consuming email typing. Yes, there are still cases like that, where people sitting just a few steps away from each other are communicating via email instead of talking face to face. Remember that there is nothing more efficient than the direct conveyance of information. Support and facilitate face to face conversation and enable people to do so.

From my experience it is a huge advantage to sense body language and moods in a direct face to face conversation. This is such an effective way of conveying information, especially in international environments with different cultures involved.

Posted in Communication Tagged with: , ,

Edward De Bono’s Six Thinking Hats

Edward De Bono’s Six Thinking Hats is a method that helps to reduce meeting times and make meetings more effective. The method is nowadays widely spread since it is simple, robust and effective. With this post I want to introduce the method briefly and also tell you about some experiences I’ve made using it.

The Method & Background

According to Edward de Bono “emotions, information, logic, hope and creativity are all crowd in on us like juggling with too many balls”. Introducing the six thinking hats represented by six colors allows thinkers to “juggle only with one ball at a time”, meaning to think structured without interference of thoughts. Putting on any of these hats will define a certain type of thinking. The hats are always referred to by their color, not by their meanings. Since colors are neutral it makes the conversation a game with rules instead of an emotional debate. The use of this method is easy. All participants must get the six thinking hats explained. After that you can just structure any conversation using the six thinking hats by their colors. The Method is described in detail in the book Six Thinking Hats.

The Six Thinking Hats 

Let’s now check out the nature or focus of each of the thinking hats and start with the color blue. Blue is perceived a cool color and is concerned with facilitating the other 5 thinking hats. Blue is the hat that a moderator would wear and is used to organize the process. This hat can be used to decide an agenda or set a certain topic for the meeting.

The white hat is about objective facts and figures. When this color is on, only facts and figures are presented. No emotions, no judgements but measurable objective values are part of “white hat thinking”.

Opposite to the white hat, the red hat represents emotional thinking. Fear, anger or rage fall under the red hat and are presented in “red thinking”.

As red and white are contrary hats, black and yellow is the next pair of colors. “Black thinking” is cautious and careful. It points out weaknesses in an idea. The black hat is often mistakenly used as the bad hat but in reality is actually the most valuable one, since it points out potential problems or potential danger.

As mentioned, yellow is the opposite of the black hat. The yellow hat covers positive thinking, is optimistic and covers hope.

After the two pairs of colors the 6 hats gets completed with the color green. Green is the color of new ideas and indicates creativity.

Using The Hats

All hats can be used together as well as independently.With single use you will have only one hat to enable specific thinking, such as green for new ideas. The hats can also be used sequentially, with each color present for a certain time and switching to the next afterwards. Discipline and time are important factors when using the hats sequentially. All participants should focus on the active hat and avoid interference of thoughts.

The 6 thinking hats are most beneficial in group conversations but could also be used individually.

I’ve used the method on several occasions and always found it very useful. Conversations run way better whilst using the hats than just using an agenda. A good point for introducing and using the six thinking hats are retrospective meetings. This would introduce participants to a new method that they would surely appreciate. After they become familiar with the method, they can apply it to any other meeting, group discussion or individually.

Discipline and timing require high attention in order to make the method work properly. Thus a moderator who is not taking part in the thinking process itself is beneficial.

Links & Sources:

Posted in Exercises, Retrospectives, Thinking Tagged with: ,

How To Do Effective Daily Stand Up Meetings

Daily stand up meetings were introduced to me together with Scrum. From my point of view having a daily stand up meeting is a very good idea for coordinating and planning the day. Since it makes a difference whether your daily stand up meeting is effective or not, I want to share some thoughts on that subject.


What is a daily stand up meeting?

Basically daily stand ups are a time-boxed meetings that shouldn’t last much more than 15 minutes. People working together meet to talk about what they are doing and if there are synergies, impediments or open questions. Daily stand ups are not meant for detailed discussions, clarifications nor should they replace other meetings. Basically it’s a meeting that should help teams to better organize and work efficiently. It is ideal for creating a plan and a goal for the day, identifying collaboration needs and raise obstacles.

The daily stand up should be time-boxed since it occurs daily and involves all team members. With that it is a cost driver and it’s in everyones interest that the meeting is beneficial rather than a boring status call.


Who are the participants?

The daily stand up meeting should be open to everyone from my point of view. Of course all team members must join, otherwise it becomes a coffee break without value. Depending on the group of participants you need to moderate your daily stand up in order to keep structure and focus.

There are other people in the organization or even clients that might be interested in what’s going on in your team. Invite them to listen, maybe they even have something useful to add. Still try to keep a clear structure and focus within the daily stand up meeting and ensure that it meets it’s goal, planning and coordinating the work day. Pay high attention that people outside the team don’t turn your daily stand up into something like a status call or reporting meeting. If this happens, cancel it or ask the people none team members to listen / participate passively.


Possible structures

There is space to try out what is the best way to do daily stand up meetings in your team. However, in my eyes there are only two alternative structures to choose from: participant focused or work item based

My preference is clearly on work item based structures. Here, one discusses anything related to work items in a prioritized order. This keeps focus on work items and is one hurdle less to falling into reporting style. For work item focused structures you need trust and self-organization in your team, otherwise individual participants could hide and not contribute.

With participant focused structures on the other hand, you have the risk that people report their work to each other or someone who is listening instead of planning and coordinating work. It usually ends up going from person to person and everyone talks about what has been done and what the next tasks are. Boring!

So, my clear preference is to hold work item based daily stand ups.  Everyone should contribute and briefly mention what is worked on, if help is needed, what obstacles are in the way. Try to avoid detailed conversation and stay focused. Remember the cost factor! …and the ultimate tip is to : go with the flow. Let daily stand ups run smoothly.


Posted in Planning, Reporting, Self-Organizing Tagged with: ,

Reality Check – Cola Doesn’t Need A Product Page

Some time ago we implemented an online shop for a large food discounter. A couple of weeks after the launch, statistics showed that the implemented product page [1] in the shop had been rarely visited.

Actually there was nothing wrong with this product page. If anything, it was a very thoughtful one, with a nice clear layout and a quite complex, but reasoned backend logic. The customer put a lot of energy into mapping all possible business scenarios, specifying details and possible exceptions. The user experience guys were happy. Everything was perfect.

The product page had only one problem: real world users just didn’t use it. Another interpretation of this fact is that the time and effort had been spent in the wrong place.

At the end the reasons were quite obvious. In the “common” online shops that sell TVs or clothes, customers would definitely visit the product page of particular product to study technical details, check fabric or compare colors. But visitors of this food delivery shop know perfectly what colas or tomatoes are. Thus, most of the people skipped the product page. They just didn’t require any additional detailed information. The food they were interested in, were added directly to the shopping cart from the category or search results pages.

Good analytics software is a foundation and pre-requisite for your decisions in the highly volatile e-commerce business. You must know what happens in your online shop and not in just any other online shop, period. You have to know who the people are that view and buy your products, what colors they like, when do they visit your shop, where they are coming from, what devices they are using, etc. etc. Without these statistics you’re just blind in your interpretations and decisions.

Don’t over engineer. Do smaller releases. Implement and launch initial release with minimal possible scope with the most business valuable stories first. This is an agile classic. You still want to consider some very valuable customer study, but it is always better to know what real life is telling you. Define, collect and interpret KPIs you’re interested in. Compare your measured numbers with the available e-commerce statistics [2]. Recognize challenges – do this ideally with your customer – and adapt with the next iteration. Address your issues. It doesn’t make any sense to implement some fancy responsive design for iPhone because everybody does it, if most of your visitors are still using desktops.

In the mentioned shop the search suggest dropdown has been extended with the “add to shopping cart” functionality (nope, Amazon, doesn’t do this). This implementation drastically accelerated shopping experience.



Posted in eCommerce, User Stories Tagged with: ,

How To Play Planning Poker Right

Planning Poker is an estimation technique often used in agile software development. All Scrum teams I’ve worked with or met at gatherings know planning poker and use it on their projects. So I assume it is very widely spread.

However, often enough I’ve seen that Planning Poker isn’t played the right way. There are certain rules for playing Planning Poker that need to be respected in order to get the full benefit of playing it. Team members reveal their estimation to each other before everyone has made an estimate for themselves. In case Story Points are used, there is often a debate about Story Points interfering the actual estimation and exchange of information in Planning Poker. This is just two of the things that could harm Planning Poker.

Before you start playing Planning Poker, ensure that everyone knows the rules and understands it’s purpose. In case Story Points are used as your estimation unit, ensure everyone has a good understanding of it. For more information on Story Points see my previous post on this topic. Also consider setting one or two reference estimates at the beginning of the project, so that everyone gets a similar understanding of the estimation unit used.

The origin of Planning Poker is the Wideband Delphi method, which is derived from the Delphi method.

The Delphi method is a forecasting method in which a panel of experts answers a questionnaire anonymously in several rounds. A facilitator then provides anonymous feedback about the results of the previous round to the participants and another round of answering is held. This process is repeated several times until the forecasts of all experts reach a consensus. The Delphi method was developed in the 1950s at the RAND Corporation.

From the Delphi method the so called Wideband Delphi method was derived. The Wideband Delphi method follows the same process as the Delphi method. Additionally experts are allowed to discuss their estimation with each other. Experts discuss differences in their estimations in several rounds and by doing so reach a consensus on estimates.

Let’s now look at how Planning Poker works, which is developed based on the Wideband Delphi method.

As well as the Delphi or the Wideband Delphi method, Planning Poker is a consensus-based estimation technique. Before you can actually play Planning Poker, all your work items or User Stories need to be prepared and introduced to the team. The team then asks questions for clarification until everyone has fully understood the requirements.

All participants get a card deck handed out. The cards show values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 if you are using Fibonacci number Story Points range. Each participant then makes an estimation and chooses one card without letting the group know which one it is yet. When all participants have their individual estimation, they reveal their cards all at once. The reason for this is, to catch each participants point of view without being influenced by other estimations or thoughts.

In the event that everyone shows the same number in the first round already, that would be the estimate. Usually this doesn’t happen and estimates vary. If there are different estimates after the first estimation round, this is the starting point for exchanging thoughts and ideas about what led to these estimates.

Let’s assume you have estimates ranging from 3 to 8 Story Points and the majority of participants estimate a 5. You may ask the participants that estimated 8 Story Points questions such as “What makes this work item an 8 for you?” or “What is the main effort you see that this User Story is estimated with 8?”. The difference between 3, 5 or 8 Story Points are then discussed. Some participants might have chosen an 8 because they were faced with uncertainty or wanted to add an extra buffer. There might also be technical issues which were not considered by the ones who estimated a 3 or 5.

Discussions should be limited to a fix timebox in order to keep Planning Poker efficient. After the given timebox has ended, the next round of estimation may take place. Again everyone should make their estimates individually without letting others know what the estimation is. Once they have finished their individual estimation, all participants may reveal their estimation at once again. If there are still differences in estimation, the same procedure as described above takes place. If estimates are the same, you can move on to the next work item or User Story.

Thats basically how Planning Poker works. Once consensus is reached, you have a single indicator as an estimation for your User Story. As mentioned Planning Poker is often played with Story Points but other estimation units may be used as well.

A few thoughts on the maturity of User Stories or work items that are estimated. You have read about setting a fix timebox for discussions. The purpose of this is to see whether discussions come to an end in reasonable time. If this is not the case, there might be too much uncertainty, open questions or lack of understanding of the work item. This is a sign that the User Story or work item is not ready for estimation yet and needs to be refined. Also limit the estimation rounds to a maximum of 5. If no consensus is reached after 5 rounds, this is also an indicator that the User Stories or work items are not ready for estimation. They need to be refined and become clearer to the participants before estimation.

Following are some of the strengths and benefits of Planning Poker at a glance:

  • consensus in estimation is reached within short time
  • structured exchange of thoughts and ideas establishes common understanding of work items
  • Planning Poker is an effective way to get estimates
  • Planning Poker reveals whether your User Stories or work items are ready or need further refinement

Sources & Links:

Posted in Estimation Techniques, User Stories Tagged with: ,

Should You Draw The Sprint Burnbown Chart?

Burndown Chart

With this post I want to shed some light on my experiences with Sprint Burndown charts. Especially the question of who owns the Sprint Burndown chart and is responsible for drawing it. In case it is not presented on a flip chart, the matter will be about who maintains the status in the used tools. Should it be done by the team that implements the software or should it be done by the person responsible for planning the scope, the product owner. In Scrum, a method of agile software development, should it be possible that the scrum master or agile coach draws the Sprint Burndown chart?

Before we narrow down the topic, let’s look at what a Sprint Burndown chart is good for. A Sprint Burndown chart is a chart type which shows work left to do and the remaining time. Burndown charts are widely spread in agile software development. In this post we will look at Sprint Burndown charts in the context of Scrum.  However, Burndown charts are not limited to agile software development and could be used wherever completion of work packages is measured over time. The picture below shows a classical Sprint Burndown chart as it is used in Scrum.

Burndown Chart

Burndown Chart

There are several people who are interested in work progress, such as product owners, team members, sponsors or clients. Also scrum masters or agile coaches have stakes in Burndown charts.

Let’s look closer at the different roles in Scrum and what interests they have in Burndown charts. In Scrum you will find the scrum master, a role with the responsibility of helping teams to become agile and preserving the teams agility. For definition and prioritization of scope you have the product owner role and for implementation the team consisting of individuals.

Having the scrum master drawing the Burndown chart is not an option. The role of a scrum master is to enable and support the team and the product owner in working in an agile way. The scrum master is there to ensure that everyone knows how to do their work according to the agile manifesto, the agile principles and the Scrum guide. Therefore the scrum master is only interested in Burndown charts from a methodology point of view, not from a progress of work point of view. Surprisingly often though, I’ve seen projects where the scrum master actually drew Sprint Burndown charts. If that is the case in your project, this needs to be addressed.

The next role that comes in question for drawing the Sprint Burndown chart is the product owner. That’s possible but not a good idea. The product owner is actually the receiver of the information reported by a Sprint Burndown chart. Product owners are interested in the progress of work and when work will be finished. They are responsible for what should be implemented, that the product is valuable and meets quality criteria. Whereas the team has to take care of how to implement the product. The product owner would have to ask the team about details of implementation in order to understand true progress of work. To keep it short, product owners are the wrong persons to draw a Sprint Burndown chart. Product owners draw Release Burndown charts, which shows the progress across several sprints.

Scrum masters and product owners are not the ideal roles to draw the Sprint Burndown chart. The team is in a much better position to do this because it knows best the progress of work that is being done. At least it should, otherwise the scrum master might have a subject to talk about with the team. The team is implementing the scope that was defined by the product owner. With that the team knows exactly if implementation is going the way it was planned or if obstacles came up which cause delays. To make this visible is the purpose of the Sprint Burndown chart.

All roles work together regarding the Sprint Burndown chart. You have a team that owns the Sprint Burndown chart and is responsible of making the progress of work transparent to stakeholders. Product owners use the Sprint Burndown chart to determine whether the project is on schedule or if the release plan needs to be updated. In case the team or the product owner struggles with their role and their responsibilities, the scrum master is there to support, coach or remind people of the rules that are underlying agile software development.

To close this post, I’ll mention another benefit that comes when teams are conscious that they own the Sprint Burndown chart and draw it. This is often the first step towards self-organization, which is the desired state of teams in a Scrum context.

Sources & Links:

Posted in Reporting, Self-Organizing Tagged with:

Improve Yourself – Accurately Estimate Tasks

Are your estimates for the duration of tasks not accurate enough? Do you spend more or even less time than you thought you would?

This is particularly unpleasant when time is limited. Accurate estimates of task needs practice. The bigger the task the less accurate your estimate usually is. Inaccurate estimates sum up and make it difficult to plan. Completion of larger work items is more difficult to predict due to a sum of inaccurate task estimates. The estimate is therefore not useful for planning.

Having experienced this in several teams, I thought of a way to test estimates and improve them. This simple exercise helped to do just this. It can be applied to any task that you are facing.

  1. Before starting the task, write down an estimation of how long you think you will need to complete the task.
  2. Note the time when you actually start the task.
  3. After finishing, record the time again.
  4. Look at the difference between your estimate and the time that you took to complete the task.
Task Estimate Example

Task Estimate Example

This exercise should be done regularly and progress should be tracked. As a result you will become more conscious of how accurate your estimates are and learn to improve them over time.

There is no magic in this exercise, it’s basically common sense.  However, from my experience it is just not done in daily work.

Posted in Estimation Techniques, Exercises Tagged with: ,

Unfold The Agile Manifesto – Part 1

„Alone we can do so little; together we can do so much“

Helen Keller

Collaboration is the subject of this post. You will learn about „customer collaboration over contract negotiation“ with considerations for daily use in software development.

Collaboration is the keyword. It is hard to imagine software development undertakings that go without contracts. With “customer collaboration over contract negotiation”, all negotiations should happen collaboratively. This means that negotiations are transparent with no hidden agendas. Pricing should be fair for all parties. If a software development undertaking starts with hidden intentions, it will become difficult to work together in a truly agile manner. One of the values of agile software development, trust, is missing from start in this case. This doesn’t mean that the parties involved wont be able to work with each other, they will just have to do so in a more formal manner. Of course, some agile elements may still be included.

Ideally trust is built over time and customer collaboration is the main focus. The contract then just formally states what comes out of collaborative sessions. So contract negotiation is fine, it just shouldn’t harm collaboration.

As mentioned, trust is essential for real collaboration. Everything else may result in a non-agile way of working. Contracts are fine to set the boundaries, without fixing scope. A high level timeline with target delivery timeframes for releases should also be included. Why timeframes? Simply because it is very hard to predict the completion of software development, even the duration of a single task can be quite tricky to determine. Does it then make sense to set a delivery date or go live date weeks or months before it takes place? Reality would kick in anyway sooner or later. So why bother planing in so much detail. Don’t get this point wrong, you shouldn’t start with something like „we will see when we finish“. Contracts should contain roughly estimated work and with this you’re able to give an indication in what week or month the work will be done.

When talking about collaboration you shouldn’t limit this to a development team, a department or a group of people only. Collaboration should be applied across all involved people. This means that everyone who takes part in that software development undertaking must have a good understanding of what working in an agile environment means. At a minimum everyone should be familiar with the Agile Manifesto including all 12 principles and also with the agile values.

Another word about collaboration and what it means in daily work. It is the opposite of „I do my thing and pass my work on to the next person in the chain“. It means working together, being open to feedback, asking others for opinions and looking for alternatives. Collaboration involves a lot of communication and the Agile Manifesto and it’s 12 principles support creating such an environment. From my point of view and also my experience in several roles in agile software development undertakings, this way of working is more fun for everyone.

In this post, I wanted to bring across :

  • the importance of collaboration for agile software development
  • the role of negotiation as part of the software development process

If you like what you’ve read, feel free to share, subscribe & comment.

Sources & Links:

Posted in Agile Manifesto Tagged with: , ,

Shopping Cart Checkout – What You Need To Know!

Checking out a shopping cart or shopping cart checkout flow is the process that comes after shopping. This happens when the user is done adding products to his basket. In the checkout phase, a shopping basket filled with items becomes an actual order. This is an essential process in any online shop, since this is when users convert to buyers. With this objective, the checkout process should boost users confidence in the online shop and run smoothly.

In this post we won’t focus on the layouts and contents of each page that is part of the checkout flow but on the flow itself. Pages of the checkout flow, for example cart details, will be covered in additional posts that will follow.

The checkout process starts after you have added items to your shopping cart and clicked the “buy now” or equivalent button. But the process of converting visitors to buyers starts earlier. As soon as a visitor comes to your online shop, he should like what he sees and become confident that he is in a trustworthy online shop. Motivation to buy can be supported additionally in many other ways, such as promotions, recommendations, customer reviews, product descriptions, nice pictures or even videos of the products for example.

Checkout Flow Example

Checkout Flow Example

When you offer buying products online you should consider how people used to buy products offline. What usually happens when people shop offline is, that they fill their basket with items, go to the checkout counter, pay, put the bought items in their bags and leave the store. So essentially they do what is necessary in order to get what they want. They don’t expect registration at the checkout counter or any other loops that are not directly linked to their goal, which is buying something. If there are promotions or other informations presented to them, it is done from when they enter the store and while they are shopping. At the checkout counter everything is purely functional, with the exception of some sweets offered to catch attention of children or other small stuff.

When we consider why people buy online instead of visiting a offline store, we come to the aspects of comfort and time savings. In an offline store shoppers can look at the products, touch them, smell them, maybe try them out and take them home right after buying. All this can not be done when shopping online. So when people come to your shop to buy online, even if they have checked the products offline before, they want to do it smoothly and without spending huge amounts of time. You should support these factors in your online shop as good as possible.

Make your checkout process easy and keep it simple. Determine whether you need to collect lots of data that users have to enter or not. Do you need to have users registered or is it only nice to have. Offer buy without registration or login for those who don’t have time for that or don’t want to be registered with every online shop that exists out there.

Performance, performance, performance! Slow online shops and slow checkout flows are turn offs for potential buyers. This would be the equivalent of joining long lines in offline stores. I don’t know a single person who enjoys this. Remember, people buy online for several reasons, one of them is saving time.

Besides performance a clear interface is key in supporting confident buying decisions for visitors to your shop and with this it supports conversion. This is particularly valid when users enter the checkout flow, where potentially their data and payment gets involved. Keep interfaces in the checkout process clear and reduce them to the minimum necessary. Avoid additional distractions and support the users confidence that he is on a trustworthy online shop. Ensure that he understands whats going on and it is secure.

With a good performance and clear interfaces you have done a great deal for your users. Now let them know where they are in the process. As you see each little detail that happens when you buy in an offline stores, provide good feedback to your buyers also online. Any action users do should have a feedback. This can be anything from an loading spinner to text, important is that there is feedback and the users get confirmation on their action. Again this establishes the visitors confidence in the online shop and gives the feeling of security.
Just to make sure, security should be implemented in your whole online shop. But if the visitors don’t notice that and feel insecure, your conversion rate will suffer.
An important form of feedback is to show progress of the checkout flow. Make transparent to users where they are in the process and what will follow.

As mentioned, I won’t go into the details of each page that is part of the checkout process. But generally speaking, you should provide buyers with information needed for their buying decision as early as possible. It is frustrating to get informed that the item you intend to purchase is out of stock after you have entered all your data.
Buyers also like to have an idea of when their products arrive. Delivery time should be made visible, even if that is not required by law in your country.
Show offered payment methods from the beginning, even before the checkout process starts.

One more point to support the visitors and potential buyers is to keep the browser back button fully functional in your online shop and also during the checkout flow. This button is very popular and people use it frequently. Don’t ignore that and make sure it works!

Now let’s have a look at the online shop owner’s perspective. You want to keep users in the checkout process once they have started it. You want them to finish it and buy in your store. Therefore avoid anything that distracts buyers during checkout. Don’t lead them to different pages, don’t show irrelevant information, don’t cause interruptions or confusion. Think about registration carefully, it is one of the top reasons for abandoned carts. Also rethink buy later features, you want to support the buy now decision.
Regarding registration, this is still a feature desired by users. Especially ones who shop frequently at your online shop and don’t want to enter all their details over and over. It might be less important for users who buy at different stores all over the internet.

So with all the information that you have read, still don’t just apply them one by one. Know your users, know your business and evaluate what is the best approach for your online shop. If you have the resources, do user tests, A/B-Tests, surveys or whatever gives you access to the information you need. Then adapt your checkout to the needs of your online shop and to the need of your customers. One page checkout might be nice and suitable for some online shops but not for others. Use a target group specific checkout process that supports your users and provides you with the information you need.

To sum up this post and generally speaking, create a nice checkout flow that feels natural to users and supports confident buying decisions. From experience I can tell the smoother the checkout flow and the shorter the process the higher the conversion rate. There are studies about checkout and conversion rates on the internet, which you should consider when creating your checkout process.

If you find this post useful share, subscribe & comment.

Sources & Links:


Posted in Checkout Flow, eCommerce Tagged with: , ,

User Stories And Acceptance Criteria In The House

User Stories and their Acceptance Criteria as the base of implementation work is shown by the example of drawing a house in this post.

User Stories are commonly used in context of Agile software development but that’s not a limitation. Acceptance Criteria will allow you to determine whether or not you have completed the implementation of a User Story. They are usually a list of 3 to 5 bullet points stating what must be achieved in order to deliver the User Story. Additionally a User Story can have optional information or constraints attached, however this will not be dealt with in this post. My best read about user stories and acceptance criteria was User Stories Applied: For Agile Software Development.

For software development to be efficient it is essential to stick to the User Story and Acceptance Criteria that you implement. Everything you implement that is not requested might result in waste or unnecessary efforts.

Here is an exercise that you can use for demonstrating the side effects of gold plating and implementing more features than actually required. This exercise can be used in retrospective meetings and other sessions with space for learning.

What you need to do for the exercise is pretty simple, draw a house. Ideally on a flip chart or something similar. In case you don’t like houses, draw a car or any other thing you could imagine the exercise works with. For this post we go with the house. Keep the house simple. This will make the exercise clearer and causes less distraction for participants. The picture below is an example that I’ve used previously.

User Story House

User Story House

Now that you have drawn the house, you basically have your User Story. The drawing shouldn’t be visible to participants yet. Write down your User Story that you will later read out to the participants. To complete the User Story you will have to add Acceptance Criteria describing features that the house must have. The list below shows what I’ve used with the house in the picture.

  • a front door
  • one window on the ground floor
  • two windows upstairs
  • a pointed roof

Remember to limit Acceptance Criteria to a maximum 5 bullet points.

Now your User Story together with the Acceptance Criteria is complete and you could actually invite participants and start the exercise. Put some pieces of paper and pens on the table and explain the exercise, so that everyone knows what to do. Set a time box between 10 to 30 minutes, that should be sufficient. Then read out the User Story and Acceptance Criteria in one flow. Participants will probably ask questions, that you have to answer in order to clarify the User Story. Once they know what to do, they can start thinking of how to do it and start drawing. Don’t worry, each drawing will look different and you will have lots of points to talk about.

A few minutest before the exercise ends, remind everyone to finish drawing. Then reveal the house you have drawn in the beginning and go through the User Story and Acceptance Criteria. Verify whether the participant’s houses meet the Acceptance Criteria and the User Story would be accepted or not. While doing this you can point out all the impacts of the participants work. This can be mapped to software development projects directly with examples from daily work.

Here are 3 examples that I’ve got on the Acceptance Criteria I’ve stated above:

User Story House - Example 1

User Story House – Example 1

Example 1 shows the the participant has paid some attention to details but didn’t meet all Acceptance Criteria. Thus the drawing will not be accepted and would need rework.

User Story House - Example 2

User Story House – Example 2

Example 2 shows a house that meets all Acceptance Criteria plus some extras that haven’t been mentioned in the User Story. This can go well in real projects but holds a strong risk of making extension of features or implementation of new features difficult. The chimney for example was not requested. In case the house owner decides to put solar panels or a window on the roof in the future, it would cause additional effort to remove the chimney. Further more this change costed time that someone pays for.

User Story House - Example 3

User Story House – Example 3

Example 3 also shows a house that meets Acceptance Criteria but has a carport attached to it as well as a tree beside. Again features that were not requested, which means extra costs and effort for something that has not been asked for. In software development projects this may be a problem since the time spent on non-requested features was already planned for other features.

The following list of reasons why gold plating or implementing features based on assumptions should be avoided, will help you to start some conversations:

  • it causes more effort and cost for quality assurance
  • it could contain bugs and prevent the User Story from being delivered
  • it extends implementation time, that causes additional costs
  • it might make it difficult to incorporate adaption or extensions in future
  • the results might not deliver the value that the User Story was written for
  • etc.

More insights may come out of this exercise and you are invited to share them in the comment section below.

After you are done with the exercise and follow on conversations, make a final statement to remind participants of the lessons from this exercise for daily work. I personally find this exercise very helpful and it often turned out to be an eye opener for conformity to requirements.

Let me know how this exercise worked for you. Subscribe and share if you liked this post.

Sources & Links

Posted in Exercises, Retrospectives, User Stories Tagged with: , ,

Get posts per Email