We dive into some of the most common mistakes a Scrum Master makes and discuss ways to prevent them.

Sprint Grooming is an essential part of the Scrum process.  Understanding what Sprint Grooming is all about and how to run sessions routinely and effectively is critical.

When introducing Scrum to your team, you want to bring it to them methodically, specifically, in a way where the team can consume it, learn it, and then begin to make it their own.

Benefits of Scrum will include but are not limited to: Better Product Quality, Faster ROI, More Control, Reduced Risk, and Improved Customer Satisfaction. We dive into the details of each benefit.

Agile Ceremonies is actually not a correct Scrum term anymore; the term has shifted to “Agile Events” or just “Events”.

When I first started to get into Agile and Scrum, roughly one year ago, it was a foreign concept to me.  Like most people, I did not fully understand it out of the gate.

Agile team size is always a topic of discussion for organizations either transforming to Agile, or even those practicing it for years.  When you look at Agile team sizes, especially in Scrum, you always want to find that ideal where productivity reigns and social loafing is minimized or erased. 

Scrum Coaches are typically brought into an organization as consultants. A Scrum Coach focuses on the whole organization or a specific division of an organization. They work with and impact multiple teams. They organize teams to allow for effective Agile development across teams.

A key artifact in Scrum is the Sprint Backlog, also called an iteration backlog. It is highly versatile but is easy to misuse. This guide shares what the Sprint Backlog is, how it fits into Scrum, best practices, and much more.

While some project management professionals may believe that they can easily retool or rebrand themselves from Project Manager to Scrum Master, the truth is that both disciplines seem to take almost diametrically opposed approaches to software development.

The use of agile development methods and practices has become something increasingly more natural in companies' daily lives. Some of these companies, although they do not admit it, implicitly end up applying some common practices, with the aim of obtaining results sooner.

I think of Scrum Backlog prioritization as if it is a restaurant experience. The backlog itself is a menu arranged to fit the customer’s needs.

In Agile regression testing, a software programmer’s primary job is to still create code, but rather than leaving the task of finding any bugs to testers, they're expected to check their code as its created for errors.

I get often asked when I work with people or teach a class how to show real progress on an Agile project. Roadmaps, Release Burnup's, Velocity, how to answer questions on delivery. We build products for external clients using Scrum and will show people how we visualize progress sprint by sprint for our customers. Showing how velocity changes, roadmap, release plan changes and most importantly how customer feedback has affected the release date. This isn't hypothetical talk but real world experiences and conversations.

However, first I will start out with showing the old ways of doing things with Gantt charts. Why the traditional way doesn't work. Comparing the Green, Yellow, Red method and how it doesn't work. The roll that into the better, agile mindset of delivering questions like when will be done, what will we get and how we communicate good and bad news to our clients.

Scrum isn't easy, but it's effective. One of the things that teams struggle with is a way to automate their testing and learning techniques like Test-Drive Development or Behaviour-Driven Development.  Both which can be implemented in both the back-end and the front-end code.

One team, I work with also automates the UI testing. One tool they use and they include as part of their Definition of Done for each feature is building a test automation using...

Over at toggl, they have a great infographic showing how you might build a car using waterfall vs. scrum vs. kanban vs. lean. We liked it a lot that we wanted to share... One of the best software development infographics around.

I thought I would share some of the real world examples of Behavior Driven Development patterns, or BDD. 

In my last post I talked about Estimating, and how I don't believe in the #noestimates movement for most situations. As previously stated, for my team, not estimating is not an option.Here you'll find some "What If" scenarios - demonstrating the clear advantages for estimating. 

What's with this whole #noestimates movement? It's a group of Agile enthusiasts advocating not to estimate and not 'plan out' work. Their reasoning: 'because the estimates are always wrong anyway'. I find this concept of not planning or estimating disturbing and unrealistic in most situations.