As a software developer, sometimes it’s easy to forget that what you’re working on isn’t just a task. You’re working for a client who has a story and a need behind every issue you take on. This customer-centric approach to work is the key to success for any organization, and agile methodologies are a way to increase the extent to which your organization is customer-focused and to which you can delight your clients.
Customer Collaboration – Client Delight
Customer collaboration is one of the core tenets of the overall agile philosophy. Agile companies embrace the belief in “customer collaboration over contract negotiation.” In other words, the business relationship can be seen less as transaction and more as a partnership. When firms actively promote this concept, it becomes easier to meet clients’ needs and create solutions that are delightful. That said, let’s look at some agile best practices in the context of client delight and collaboration.
Iterative Development: deliver value with every step
For the sake of this article, we’re going to assume your team operates on a two-week sprint cycle. At the start of your sprint, you review the product backlog and move the necessary tasks from the backlog to the sprint. Each task is a part of the interactive development cycle. Over the next two weeks, those small, iterative tasks form a chunk of functionality that can be delivered to clients.
Agile and iterative development go hand in hand. Each small task in the sprint goes through the same steps. First, the team plans what “Done” looks like for those specific tasks. Then, the design unfolds. How will it look? How will it function? Next, it moves into development: the actual coding necessary to complete the tasks. Finally, the team tests to make sure the new software functions as expected. When all four of these are completed successfully, the task is finally ready to be marked Done.
Of course, iterative software development has both pros and cons. On the plus side, smaller steps are more efficient. It reduces risk by keeping the team focused and the project on schedule. Iterative software development also can help teams spot bugs earlier in the development process before they impede future development.
There are, however, also some downsides to iterative development. Some clients prefer to be hands-off, but this conflicts with the customer-centric nature of agile. It can be challenging to keep them involved with the process if they have this mentality. Also, it can become easy for your team to lose sight of the “big picture” — the final project — when they work in an iterative method.
User Story
One way to keep both the client and the team connected is through user stories. What are user stories in agile methodology?
First, understand that writing user stories in agile is critical to delighting your customers and meeting their expectations. As we mentioned, it’s important to keep the customer involved during the entire software development process. User stories are driven by the customer’s experience and explain why some functionality or needs to be developed or improved. The majority of the content in user stories comes directly from users themselves — not your team.
As you collaborate with your client, you’ll unpack these task-specific user stories and articulate them to your team so everyone understands the goal or goals. User stories are written from the perspective of the software user. Several examples of user stories include:
- As a customer, I want to access my checking account online so that I can see my balance.
- As a writer, I want easy access to my toolbar so that I can style my text.
- As a videographer, I want to place markers so that I know what parts to edit later.
Revise & Validate
Of special note is the importance of revisions and explanations in iterative development. Again, just to emphasize, your customer should be involved throughout this entire process. As you continue working on or planning sprint tasks, you’re eventually going to come to one that doesn’t make sense. Alternatively, you may run across a task that doesn’t seem relevant to the big picture. It’s important to clarify these questions with your customer and to revise the product Backlog as necessary. Remember: it’s customer collaboration over contract every time!
A Time-Boxed Approach
Have you ever had that one task that just seemed to take forever? And, it wasn’t because it was difficult per se. But rather, things just kept getting in your way to prevent its completion. A solution is to employ timeboxing in agile systems.
What is timeboxing in agile? It’s exactly what it sounds like: the development team only allows a specific length of time for each task. When the time is up, the team analyzes how much progress the team member made towards completion.
Timebox in agile is important not just to sprint tasks, but all aspects of the system. This includes the planning meeting at the start of your two-week sprint as well as the retrospective. Timebox is also used for daily meetings. The goal is to remain on task and focused so that all tasks assigned within your sprint can be completed successfully.
Value stream analysis
A key component for success is value stream analysis, a technique employed often by agile teams to deliver maximum value as quickly as possible. A value stream map forces you to look at each step of the product development process to understand how you’re creating value and where relevant processes could be optimized. Look for potential improvements to streamline future sprints and remove bottlenecks from your value streams. A value stream map can take various forms, but the goal is always to minimize waste and reduce the likelihood of bottlenecks preventing you from delivering value.
Automated Tests and Continuous Integration
QA is always a major consideration for agile teams. Every time something goes wrong or needs improvement, QA and customer success specialists make sure the issue is fixed either immediately or in the next release. Automated tests can warn you of issues that need to be fixed immediately, before your customers ever touch that version of the product. The more functionality that can be tested before software is released, the better. Automation allows agile teams to test much more functionality much more quickly than humans could test themselves.. Automation within an agile context means tests are added as new functionality is developed, rather than writing tests for all functionality after implementing it. Continuous integration means that tests are run when code is pushed to a common code base, giving developers insights into potential issues immediately.
Some benefits of automated testing and continuous integration include:
- Saves time over manual testing when results are needed quickly
- Instant feedback and accountability for developers
- Increases customer satisfaction by reducing defects in the final product or release
Programming in Pairs
Pair programming in agile methodology embraces a collaborative approach to developing software. In pair programming, two members of the development team will share a single computer or workstation and one of them will act as the “Driver,” writing the code. Meanwhile, the other acts as an observer, sometimes called a “Navigator,” to check for accuracy.
There are several advantages of pair programming. Because each member of the pair swaps roles frequently, software engineers feel more confident in their work. It creates flexibility as each member of the pair learns from the other. It’s also great for senior engineers to train junior engineers as well as teaching new hires how to work within an agile system.
Product Backlog
All agile projects have a product backlog. On starting a project, your team will analyze the project’s scope and break down each component into smaller items. These are the “tasks” we’ve been referring to throughout this blog. During sprint planning, your team will identify which tasks are both necessary and able to be completed during the next two weeks. The remaining tasks stay in the backlog.
This is far more efficient than a normal to-do list, as items can be added to the backlog as you go, and subsequently planned into future sprints depending on their urgency. It also allows the team to decide how to approach the overall project and meet the expected launch date.
So what is Backlog grooming?
Agile backlog grooming, sometimes also referred to as backlog refinement, means taking a look at what items remain in the backlog to identify what needs to be changed, gotten rid of, or added. Backlog grooming is necessary to keep the backlog organized and relevant. Product backlog grooming weeds out user stories and tasks that may no longer be relevant.
Key Advantages of Product Backlog Refinement
As we mentioned, backlog grooming is sometimes referred to as refinement in agile systems. There are several advantages of this recurring analysis, including:
- Eliminating risks: the more relevant the backlog is towards the end goals, the easier it becomes to prioritize items and deliver value on time
- More efficiency: by deleting unnecessary items from the backlog, teams are freed to focus on their work, knowing that the remaining tasks are crucial
- More effective sprint planning: nothing slows a team down more than redundancy. Backlog refinement removes this from the spring planning equation
- Clarity: developers better understand what needs to happen within a sprint. Product backlog refinement in agile clarifies expectations and requirements dynamically
The main goals of Backlog Grooming
The primary purpose of product backlog grooming is to increase both efficiency and effectiveness of the whole team. It allows for more effective sprint planning and retrospectives, ensures large tasks are broken into manageable components, exposes areas of improvement, and prioritizes user stories based on value and time required.
Stages and activities within Backlog Grooming
The Scrum Master and Product Owner often guide the backlog grooming process. However, members of the development team should also be involved in backlog grooming. It’s recommended grooming last no more than 5% of the total sprint’s hours, so in our example, it would be no longer than 4 hours.
Epics in Agile Methodology
Initially, not all components of the project may be broken down into smaller segments due to complexity. Epics in agile methodology address this situation and encourage teams to look at applying smaller user stories to a larger area of functionality so that the project can move forward.
What is Epic in agile methodology?
In a nutshell, an epic is a task that may have seemed simple at first, but gradually grew to an exponentially larger size.
How Epic is used in Agile Software Development
So how large are we talking exactly? The magic number is 5. If you have that many user stories assigned to something, it’s not just a task anymore. It’s an epic. Define it as such, and look for ways to break it down into manageable sub-tasks.
Epic Example in Scrum
Let’s take a look at an example. Let’s assume your customer is a banking customer and the initial user story is, “As a customer, I want to access my account online.” There are dozens of potential sub-stories within this, such as:
- As a customer, I want to view my recent transactions online so that I can protect myself from fraud.
- As a customer, I want to view my previous statements online so I can predict future expenditures.
- As a customer, I want to transfer funds online so that I have money where I need it, when I need it.
- As a customer, I want to pay my bills online so that none of my services are cut off.
- As a customer, I want to make deposits with my smartphone so that I don’t have to go to the bank.
- As a customer, I want to track my spending online so that I can understand the effect on my budget.
We’re already at six user stories, and we’re just getting started. Without a doubt, the initial user story has become an epic and needs to be broken down into separate stories that can be addressed one or two at a time.
Creating an Agile Epic
It’s time to learn how to write an agile epic. The Product Owner will primarily be responsible for detailing epics and breaking them down. First, look at your customer’s goals. Is the task more complex than it initially seems? Probably! Look at it from a technical standpoint. How will customers use the software? Make notes about each potential behavior or desired outcome, as each specific one may be a separate user story. Again, if you go beyond 5 stories, you have yourself an epic!
How to Write Epic User Stories in Agile Product Development
Epics are defined by their user stories. Broad epics, such as our banking example, may seem simple at first, but it’s important to analyze what the story entails. Clearly, it’s not feasible to address every aspect of online consumer banking with just one user story.
Therefore, once you’ve identified what it means, start breaking it down by user behaviors and goals. Start small and work logically. A visualized user behavior flowchart can help identify additional behaviors (pay bills, make deposits, track spending, etc.). Work with your colleagues who have similar experience with epics to help you break down what may at first seem simple into its parts.
Most importantly, stay focused. Don’t let the complexities of the larger project derail your progress.
Throughout all of this, focus on the core philosophy we mentioned earlier. Agile elevates customer collaboration over contract negotiation. As you develop your user stories, refine the product backlog, and build epics, remember that your customer should be included in the process as much as possible. Ask lots of questions and have customers critique potential solutions as you develop them.
Here at Zazmic, we’ve developed a project management and product planning tool called Z-Stream. It allows you to keep your customers at the center of all of your agile workflows. Interested in learning more? Contact us today to find out how Z-Stream can help you delight customers!
