Overtime is the first refuge of bad management. When teams get behind—as they often do, even with agile—managers search their bag of tricks for a solution. All too often, the solution they pick is the solution that was used on them before they became managers: Overtime. The problem is, overtime didn’t work then, and it won’t work now. Four Things to Try When Teams Fall Behind When a team falls behind schedule, there are many things besides overtime that a manager could try. They could: Add people to the team. Drop a few requirements. Relax a few requirements; that is, not drop them but do a s ..read more

Some Scrum teams use a definition of ready to control which product backlog items can enter an iteration. What does definition of ready mean? It means that the user story or product backlog item meets a set of team-established criteria as to whether the story is ready for a sprint. These criteria are typically things like small enough to fit in a sprint, has acceptance criteria, and so on. You can think of a definition of ready as a big, burly bouncer standing at the door of the iteration. Just as a bouncer at a nightclub only lets certain people in—the young, the hip, the stylishly dress ..read more

What do product owners do? A ton! They work to keep stakeholders, customers, and users happy. They do market research and examine data to help keep the product on the right course. Product owners work closely with team member and make themselves available to answer questions about work in the current sprint. And they ensure the team has a steady stream of new user stories for future sprints.  The product owner role and responsibilities are vast. Good product owner follow good practices so that they can avoid 7 costly mistakes. Product Owners Try Not to Interrupt the Sprint Go ..read more

There is no magic formula that must be used to create user stories. Teams can write user stories in any number of ways. But the most popular way of writing user stories, and the one I advocate for, is with this template: As a …, I … so that ….. This agile user stories template originated with agile coach Rachel Davies at a UK company, Connextra, in the early 2000s. It has since become a recognized standard for expressing user stories. To understand why it has stood the test of time, we'll look at the elements, advantages, and drawbacks of the three-part story template. The Three-Part ..read more

One of the 12 principles in the Agile Manifesto is "Working software (or product) is the primary measure of progress." That’s why agile teams (e.g. Scrum teams) whether developing software or any other product, work together to deliver something of value to their customer each and every iteration. For this to happen, agile teams embrace concurrent engineering. Concurrent engineering (or simultaneous engineering) is a way of working where tasks overlap, rather than happening in a series of phased handoffs. The Main Benefit of Concurrent Engineering Contrast overlapping work with sequential eng ..read more

Almost every year, on or around April 1, Mountain Goat Software releases a new mock product for the agile industry. This year, we’re introducing the Scrum Police. On the new, official Scrum Police site you can report crimes against Scrumanity, view a log of recent convictions, and even confess your own crimes before you are turned in by your teammates. Join the Fun at ScrumPolice.com The crimes range from truly silly to a little bit detrimental to your team’s well-being. Here are just a few examples of some that won’t really land you or your team in jail, but I wouldn’t necessarily recommend ..read more

A common challenge with writing user stories is how to handle a product's non-functional requirements. These are requirements that are not about specific functionality ("As a user of a word processor, I want to insert a table into my document."), but are rather about an attribute or characteristic of the system. Examples include reliability, availability, portability, scalability, usability, maintainability. As you can see from that list of examples, non-functional requirements are often referred to as "-ilities." Of course, not all non-functional requirements end in "-ility." We also have sec ..read more

A story map is a two-dimensional visual representation of the things a user wants to do. (The idea for story maps in software development—and the name—comes from Jeff Patton.) Story maps are a way to create a shared understanding of the product, to visualize user needs, and to elicit user story ideas during story-writing workshops. I tend to create them using sticky notes and paper on a big wall or, if we’re remote, on a virtual whiteboard. Start with a Significant Objective I recommend focusing story maps on a single, significant objective or MVP (minimum viable product). The MVP or objective ..read more

User stories are simple, powerful tools but only if they’re written in a way that encourages communication, helps you prioritize and plan a product, and focuses on end-user value. A great way to ensure your stories do all of this is through a user story-writing workshop. Scheduling a workshop to write user stories can make it easier to generate a product backlog. Running a story-writing workshop opens up a whole new set of questions for people. Questions like: How often do you hold a workshop? Should it be once a year? Every iteration? Somewhere in between? How do you know who to include ..read more

How do agile teams achieve cross-functionality? Hint: Contrary to what you might have heard, cross-functional does not mean everyone on the team must know how to do everything. Every sandwich shop in the world has figured out how to work cross-functionally. So it's surprising to me that so many agile and Scrum teams still struggle with what it means to be cross-functional, especially when it comes to balancing specialists on an agile team. Think about the last time you watched a team fulfill your order for a sandwich. Likely, you noticed that there were one or two specialists—someone who only ..read more