5 Tricks To Make The Most Out Of Your Daily Scrum Standup

According to the Scrum Guide, the Daily Scrum (also referred to as Stand-Up Meeting) is a 15-minute, at which the Development Team plans work for the upcoming 24 hours. Consequently, meetings are held every single day during each Sprint.

This well-known agile method is used by 86% of Agile Teams based on the findings of The State of Agile Report. Although the aim of the Daily Scrum is to sustain progress towards the Sprint Goal while supporting transparency and eliminating impediments that could block the optimal workflow, sometimes things jump the tracks. What are these factors and how can you rule them out to improve the efficiency of your meetings? We’ll fill you in on the 5 most significant best practices to follow!

  1. Have a Seasoned Scrum Master Conduct The Daily ScrumAn experienced Scrum Master is indispensable for effective Daily Scrum meetings. They make sure that the Team utilizes Scrum in accordance with Agile techniques and strive to eliminate obstacles that come forth throughout the Sprint.
    Problems arise from such simple factors as Team members not having a proper grasp on the philosophy, practices and values of Scrum. This starts a chain reaction of misunderstanding, confusion, disorganization, loss of focus, bad time management and worse quality product.
    A skilled Scrum Master who reviews the Team’s performance regularly can identify and neutralize barriers to maintain a productive workflow.
  1. Make The Subject and Priorities of The Daily Scrum ClearMaking the most out of your Daily Scrum meetings involve setting up the topics and priorities to be covered beforehand. As a result, that 15 minutes of conversation remain focused and disciplined. Also, keep the discussion universal. Getting lost in reports and details that only a couple of Team Members understand might be a major setback of the meeting. Instead, put emphasis on talking through tasks with imminent due dates.
  1. Minimize Backlog Disturbance

    It is unadvised to alter the backlog subsequent to what has been determined during the Sprint Planning. Naturally, urgency can override this theory, but it comes with a risk of the Team not being able to release product development by the final deadline of the Sprint.The best way to prevent this is to have a skilled Product Owner who can reduce interruptions to a minimum and handle the backlog effectively.
  1. Set Daily Goals During Daily Scrum Standup During Daily Scrum meetings, devote time to setting goals to be achieved in the next 24 hours. The Scum Master can make up their mind to either determine universal goals for the entire Team to work towards, or specific ones only applicable to the developers for example. This helps keeping the Team focused on tomorrow’s deliverables.

Related: Agile Quick Tip: Using a Shared Daily Goal to make Your Sprint more Valuable

  1. Manage Assignments In The Task BoardWithout the use of project management tools the Team might be more prone to getting lost in details, missing deadlines and prioritizing inappropriately. Therefore, make sure to add all tasks with their respective assignees, deadlines and details to a task board. It’s a handy tool to track progress on assignments and identify which area needs extra attention.

Related: Agile Quick Tip: Conduct your daily scrums in front of the board

Wrapping Up

Semi-productive Teams are not a rare phenomenon in organizations. However, it’s easy to cure dysfunctions with a handful of simple practices. Having experienced professionals on your Team, preparing clear-cut Daily Scrum topics and priorities, creating daily goals, reducing backlog disruptions and using project management tools are all excellent methods to make the most out of your meetings.

Feel like your Team could benefit from some additional training? Take a look at our coaching offers!

Your Most Frequent Agile Software Development Questions Answered

As you may know, for most companies today, rapid software development is essential, given the environment of ever-changing expectations. More and more companies realize the value of Agile. In contrast to traditional methods, this methodology allows for fast adaptation to customers’ expectations; provides a framework for products of the highest quality and helps to develop a viable version of a product relatively fast. Sounds good right?

Should you be intending to give it a try, or just get to know a little more about it, we got you covered. Here are some of the top Agile software development questions that help you get a better picture about the process.

Is Agile only used in IT?

It originates from IT; however, several diverse industries have adopted the methodology in some way and shape, including but not limited to the finance, automotive, healthcare & pharma, and engineering industries.

What is Agile?

Simply put, Agile development software is a collection of best practices; namely, that the development process is broken down to pieces in a way that each development cycle adds an additional functional feature to the software. The Agile software development methodology has 12 basic principles, laid out in the Agile Manifesto.

  1. Are there multiple Agile methods?There are indeed. Agile has various flavors; some of the more popular ones include Scrum, Lean, Kanban, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM) and Feature-Driven Development.
  2. Which one suits my project best?This always depends on your specific goals, the product and the company itself. There’s no one-size-fits-all here; you should take the time to examine which methodology is the most appropriate for your project.
  3. What makes this approach better than traditional methods?Agile software development methodology allows for a user-centered development process. The software is quickly released, and customer feedback can be built into subsequent versions
  4. Is it the customers who tell what the product should look like?Yes and no. They’re not telling what and how you should develop, instead what they need and consider important in a given software. That feedback should define the product itself. Agile helps by shifting the development process from feature-centered to user-centered
  5. Is this method faster than other ones?Chances are it is, especially in contrast to more traditional systems. Agile software development allows you to build a functional raw version, that could be used to gather feedback from users that will later be built into the software until it meets their maximum satisfaction.
  6. Do customers get a half-baked product?They don’t. What they get is a minimum viable product (MVP) with usually one initial feature. Think of sharing photos as a feature on Instagram. One basic, yet fully viable feature is not much, but can be used as a starting point for further development.
  7. How long does the Agile software development process take?It always depends on the very complexity of the thing that’s being built. The advantage here is that an early version can quickly be released to the public.
  8. Can you save money with this project management methodology?Most certainly you can, though in an indirect way. Since Agile software development allows for releasing a very basic version of a product, no time and money is spent on developing features that eventually will turn out to be useless. Continuous feedback helps you better understand your target audience, thus making marketing more effective and simultaneously cutting its costs.

Closing Words

Agile is indeed an effective method of running projects, and not just in software development. However, there are some prerequisites for it to work. One is a company structure that allows for cross-functional teams. Another is choosing the right framework for a particular project. In order to make things nice and smooth, try implementing the approach in smaller tasks to see what issues arise that need to be changed or improved upon. 

Improving your code quality

Do you know what’s common in the universe and customers’ expectations? Both of them keep growing at an increasing speed. You might even argue that neither of them has any apparent borders, but this might not be true for the former… Anyway, if you and your team want to keep up with the ever-increasing demands of your customers, you must start implementing some best practices when it comes to improving code quality.

Here we give you a couple of tips that can help you improve your code in an agile environment.

Defining code quality

Although every organization has their own unique set of requirements, broadly speaking, code quality can be measured by assessing a few key aspects of it.

  • Is it secure? Cybersecurity isn’t only a hot topic, it’s also a factor that must enjoy top priority when it comes to coding. In a world where a simple security bug can cost your users millions of dollars, you simply cannot afford to overlook this aspect.
  • Is it clear? If you get hit by a bus tomorrow, will there be anyone in the world to deobfuscate the mess you have created? Seriously, though, good code is easy to read and follow along for fellow developers without much effort. Try being consistent with naming and follow the style guide. Also, feel free to add comments wherever necessary so that it’s easier for others to pick up later on if needed. 
  • Is it reliable and efficient? No one likes bugs and crashes, especially users who can’t do much about them except for switching to another product. One of the cornerstones of code quality is how it performs. On that note, good code performs the task using the smallest possible amount of computing power, memory etc. This always gives you room for further optimization.
  • Is it easy to maintain and extend? IT is a rapidly evolving environment. Today’s state-of-the-art software is tomorrow’s dinosaur. Good code, however, is in a way futureproof, meaning it can easily be extended and modified to keep up with the latest technological developments and expectations.

Best practices to improve code quality

Based on the above points a few best practices to improve your code quality might be

Making it easy to read

No one likes decoding (excuse the pun) another’s mess. Agree on clear and easy naming conventions and try maintaining a clear folder structure.

Add comments

So that anyone can understand your logic and can continue your code later on. Adding comments and explanations is especially important when you’re doing things the complicated way. Keep an eye on documenting things, as they might come in handy later.

Keep it simple

Use third party libraries wherever you can. There’s no need to write every single line by yourself when others have given you the building blocks to work with. That way you minimize the risk of making mistakes and might even make your code more clear and efficient.

Closing Words

Here we gave you some tips on improving code quality in an agile environment. Each company is different, but these practices seem to work all across the industry, so utilizing them will surely benefit your team and also the users of your product.

Common Habits That Keep You From Sustaining A Healthy Product Backlog

A product backlog orders tasks into a list and prioritizes them, so the developers know which items to deliver first. The roadmap and its requirements provide the foundation for the backlog, which usually consist of the following elements: user stories, bug fixes and features.

Although the whole scrum team works jointly on the product backlog refinement, the Product Owner owns it and is typically responsible for sustaining its items. Of course, just like every other component of a Sprint, the backlog can also run up against obstacles. Below we’ll spell out the most common mistakes a Team can make to hinder progress, and how it can keep the tool running healthy.

 How To Maintain A Smoothly Operating Product Backlog

After the product backlog is determined, it should be frequently monitored to prevent or rule out any impediments. It’s the Product Owner’s task to regularly review the tool prior to iteration planning sessions to make sure that the appropriate priorities are in place, and insights from the previous iteration has been included.

As the product backlog expands over time, Product Owners decide, which items to put into the “near-term” and the “long-term” category. The former contains items that are featured on top of the list and are more detailed. Consequently, the latter category is for tasks that are less comprehensive and important.

Apart from being a huge to-do list, a backlog serves another significant function. It constitutes a link between the Product Owner and the developers. The former might alter the prioritizes within the backlog on account of the refinement of estimates and feedback. However, it’s not advisable to make significant changes once processes are in motion, since they have a potential to interrupt the developers and cause them to lose focus. According to a study conducted on interruptions affecting developers, it’s best to keep the water as still as possible and allow some ‘quiet time’ for the experts to concentrate on their duties. This way, developers got 80% of their work done within a couple of hours. 

Related: Agile QuickTip: Limit Your Agile Teams Product Backlog

Common Blockades Affecting The Product Backlog Management

  • Update blackout: The product backlog is restricted to local use and is shared rarely. This practice keeps interested parties from receiving news.
  • Importance threshold set too narrow: It’s quite a frequent mistake that Teams only put maximum effort into those items that are directly connected to customers. As a result, prioritization may get distorted and the overall work only half efficient.
  • Lack of modification: If the Product Owner builds up the initial backlog and fails to modify it based on feedback coming from customers and developers, it could cost the success of the project.

Wrapping It Up

A product backlog is used to give the Team guidance on how to deliver a successful project. In order for this to happen, adequate planning and organization is key. Only with these assets is it possible to keep the tool running in order and facilitate productivity and the ability to handle constant change. 

Efficient Sprint Planning: 10 Tips That Can Be A Real Gamechanger

Sprint Planning is one of the most significant elements of the Scrum Framework. Essentially, it’s a session, that’s held after the Sprint Retrospective and is deemed the first day of the next Sprint. Since better planning results in a substantially higher chance to reach the Sprint Goal, it’s a factor not to be neglected. 

Below we’ll share with you 10 tips to help you execute a successful Sprint Planning meeting. Let’s get started!

On The Way To Top-Notch Sprint Planning: 10 Golden Rules To Follow


  • Finish Backlog Refinement Prior To Planning
    Before the actual Sprint Planning would set off, the Product Owner should complete refining the Product Backlog, with special attention to User Stories. This is a major time-saver tactic, that allows the Team to focus on planning and determining the Sprint Goal during the meeting.
  • Roadmapping And Creating An Agenda
    Important components to be reckoned with before the meeting, as they pave the way to a more organized workflow and serve as reference points to the Team.
  • Ensuring That The Roadmap And Product Backlog Are In Harmony
    If the Product Roadmap and Backlog work in accordance with one another, the input to the planning session is considered optimized.
  • The Sprint Planning Is Conducted By The Scrum Master
    The Scrum Master needs to take care of scheduling, proper communication, and all essential resources and tools in order to hold a professional meeting.

Related: Agile QuickTip: Use a Calendar to Make your Sprint Planning Meeting More Accurate

Aspects To Look Out For During The Sprint Planning

  • Time And Duration
    Try to reserve the same time-box for your session each time to make sure that all Team Members are free in that time slot. Choose a suitable time based on people’s feedback and aim to schedule the meeting far in advance to avoid it being forgotten.
  • Include Sprint Review Feedback From Stakeholders
    Gather all insights shared by stakeholders throughout the Sprint or during the Sprint Review and include their feedback into the Sprint Planning to deliver a better product.
  • Determine The Sprint Goal
    At the end of the meeting the Team should decide about the Sprint Goal. According to The 2020 Scrum Guide, this is done by answering three vital questions: “What is our goal?”, “How are we going to achieve it?”, and “Why is this Sprint valuable?”.
    The Sprint Goal should neither be too simple nor overcomplicated: set it challenging and exciting enough to keep the Team motivated and engaged.
  • Divide And Conquer
    The ancient saying proves to be very accurate when it comes to Sprint Planning. Aim to split up tasks into more manageable chunks to be able to keep track of processes better. Here’s an extra tip: it’s advisable to break down complex tasks into smaller subtasks that’s completion takes maximum a day.
  • Avoid Undertaking Too Many Tasks At The Same Time
    Learn from previous Sprints and only take up as many tasks as rationally manageable within a certain time frame. Otherwise, you’ll only create confusion, disorientation, disorganization in the Team not to mention the greatest collateral damage: time loss.
  • Stick With Your Sprint Goal
    After the Team made a decision about the goals, they must be kept intact. Naturally, the Team may run up against obstacles throughout the Sprint where alterations cannot be circumvented. In such a situation each member should accept the need for change and move forward together. To prevent delays and confusion, aim not to modify the Sprint Goal mid-way.

What should we do with Agile Backlog items that have been there a long time?

What is Agile backlog refinement? And What to do with it?

Product backlog items are all the tasks we hope to complete before we deliver the product to our customer. Every now and then, we run into some ideas that were sourced a long time ago: they are still things we might want to do in the future but we just haven’t done them up till now. 

How to apply backlog refinement correctly for items which have been there for a long time?

One idea that might really help in backlog refinement is to apply an expiration date to all your product backlog items. You can choose, let’s say, 12 months in the future, or even 18 months, for each item. And then, treat it like you would any expiration date that’s on any item in your fridge, for example.

When you open up your fridge and see that carton of milk with an expiration date that is a month off in the future, you grab and pour it without any concern because you know it’s nowhere near the expiration date. As you get closer to the expiration date, well, we’re not that confident now. We might have to sniff it, open it up, and look inside just to make sure it’s okay before we pour it and we drink it. And then if it’s a month past it, well, you go right past it for a newer can of milk. 

So, this is how we should treat the items in our product backlog. If an expiration date is in the distant future, don’t worry about it. Prioritize the item and manage it like you would any other item in your product backlog. But as you approach that expiration date, then, it’s time to really give it a sniff test. Let’s review it. Let’s evaluate and discuss it to figure out if it still needs to be there. And if a month goes by or some amount of time goes past the expiration date, well, maybe you should just throw it out – get rid of it just like you would that spoiled can of milk!

Liked this Agile QuickTip? Just wait until you hear the others! Head to my catalogue to watch the whole series on YouTube, and let me know which one is your favourite, or the most effective for your Scrum team! You can also visit our website, thinklouder.com where you’ll be able to learn more about our training and coaching offerings.

Should we have all sprint tasks assigned at sprint planning?

Sprint Tasks Tips: Staying Focused when Agile Sprint Planning

Assigning tasks at sprint planning makes us task-driven or more focused on our tasks than the goal of the sprint. For some time, it looks like we’re making rapid improvements until some tasks get blocked. Then, we just move on only to later on realize that we haven’t fixed all those tasks that were blocked. Now you’ve got just a little bit of time to resolve those things. More than that, when we’re task-driven, collaboration tends to be a last resort rather than a first resort.

Here’s what I mean:

Imagine Bill and I were on the same Scrum team. He’s a developer, I am too. If Bill is stuck on something and he comes to me for help. If I stop working on my task to help, I put at risk my ability to be successful because we’re only successful if each individual completes their task.

Not only that, I’m actually putting our sprint at risk. To avoid that, I’m more likely to make suggestions to Bill for some things he can do on his own. If it doesn’t work, he’ll come back and I’ll propose a few more until I run out of things that I can suggest. Then, I’ll ask to sit together with him and see if we can resolve this. Again, you see how collaboration is a last resort here. 

Contrast that with the “just in time” approach where everyone working on the sprint is focused on that sprint goal and assigns themselves a task not at the beginning of the sprint, but when it is needed. The result? We learn from each other, build better and make real improvements. 

Liked this Agile QuickTip? Just wait until you hear the others! Head to my catalogue to watch the whole series on YouTube, and let me know which one is your favourite, or the most effective for your Scrum team!

What are the Benefits of Agile and How does Agile save us money?

Benefits of Agile Explained – How to Realize Agile Cost Savings? 

Agile benefits are all about delivering the most valuable products or features in the least amount of time by prioritizing the highest valued things and then delivering them through to completion very quickly. With agile, we get to accelerate the returns so we can reap the benefits sooner. 

Put another way, the benefits of agile are about focusing on what matters more to the customer and optimizing those important features of the product, while disregarding unnecessary things that would slow us down. Agile encourages short loops, allowing teams to adjust and pivot their projects quickly based on customer feedback, instead of waiting until the end of the project to make changes. 

Lots of people ask: How does agile save us money?

It doesn’t. The only way you’re gonna save money with Agile, or with Scrum is by avoiding investing in things you shouldn’t be investing in at all. Agile is not about saving money. It’s about accelerating value – highlighting the things that you really need and then delivering those most valuable ones in the shortest time possible. That’s how we reap the benefit of Agile!

Liked this Agile QuickTip? Just wait until you hear the others! Head to my catalogue to watch the whole series on YouTube, and let me know which one is your favourite, or the most effective for your Scrum team!

You can also visit our website, thinklouder.com where you’ll be able to learn more about our training and coaching offerings.

Why should the product owner attend the daily scrum?

Product owners, the team members who’re responsible for investing in the product that we’re delivering, are not mandatory participants of the Daily Scrum. But as people shepherding the investment, they are interested in them because it’s a valuable 15 minutes spent synchronizing with the team: an opportunity to be updated with what’s happening with the product. 

What if your product owner never shows up to any of your team’s daily scrums? That’s weird. 

What if your product owner never shows up to any of your team’s daily scrums? That’s weird. 

You want to go and figure out why because this is one of those agile smells – the symptoms of a problem that may not be revealing the problem itself. Just like you would when you notice an unusual smell in your kitchen, you need to sniff around to pinpoint what it is. Maybe the things we’re working on aren’t a priority to our product owner. Or we convinced our product owner to invest in what they don’t value or understand. In that case, we should stop and speak with them. 

If your product owner doesn’t attend the daily scrums, don’t wait too long to start sniffing. Because if they’re too busy to show up, they’re probably too busy to do the other things we expect of our product owners. So, take a deeper dive, starting from the obvious reasons why and then, the not so obvious reasons so you can uncover the truth and fix the situation in time.

Liked this #AskG Tip? Just wait until you hear the others! Head to my catalogue to watch the whole series on YouTube, and let me know which one is your favourite, or the most effective for your Scrum team! You can also visit our website, thinklouder.com where you’ll be able to learn more about our training and coaching offerings.


Team members in distant time zones

What should we do if our team members are in distant time zones?

Team members can be difficult to manage when they’re in distant time zones because the time overlap is so small that there’s not enough opportunity to collaborate or participate in events.

So, how do you turn things around, empower your team members and boost productivity?

Let’s take a look at a situation where you have some team members in New York or Boston, and other team members in India or China, for instance. You might be getting only an hour or two of time zone overlap, and that’s not going to move your Scrum team forward.

To get more time, you can try once every other week to have your team members shift their work schedule by a few hours. Those in Boston can start their day earlier by a few hours while those team members who are in India can start their day later, and also end it a few hours later. This way, we can increase the short time overlap we usually have into seven or eight hours of meaningful collaboration.

I’m a big fan of doing it this way even though it might be inconvenient at first. But think of the long term benefits: if we’re doing it infrequently, we can enjoy the extra time to work together on events like sprint planning or processes that require the power of crowds to maximize efficiency.

Liked this Agile QuickTip? Just wait until you hear the others! Head to my catalogue to watch the whole series on YouTube, and let me know which one is your favourite, or the most effective for your Scrum team! You can also visit our website, thinklouder.com where you’ll be able to learn more about our training and coaching offerings.