About Andy

Product Owner, Consultant and Scrum Practitioner. www.linkedin.com/in/andrewmhayward

Postpone technical details as long as possible, despite what your PM tells you

I’ve always been a firm believer that whether you’re Agile or Traditional, it’s important to postpone describing technical details as long as possible. It’s very tempting to start to solve problems ASAP, because there is something very satisfying about solving puzzles. Also, many project managers and others who are being held to deadlines will push to start design and coding as soon as possible. However, I believe in, as someone I met recently described it to me, a “back to basics” approach.

One challenge I often face is when a client pushes for me to start technical discussions with the users. Their argument Continue reading

How to avoid missing requirements

A common cause for consternation in development projects is when requirements or features are missed in the early stages. Missing requirements in traditional development can be very painful, as the gaps are often discovered either in Quality Assurance or in UAT, or later, which means the majority of the development budget and schedule has already been spent and addressing these new requirements will set the project back a significant amount of time. When using an iterative and incremental method, such as Scrum or Kanban, missed requirements are less problematic because development is usually still ongoing and the requirements can be added to a backlog and re-prioritized. However, this can have adverse effects on the release plan and overall budget, and there is still the risk of learning of the gap too late.

Continue reading

How do we write good user stories?

The topic of writing user stories has come up so frequently that I felt a burning need to write something on the subject.

I’ve seen posts on newsgroups and I’ve received questions from clients about the “correct” writing of user stories. Do we use “Shall” or “Will” or “Must?” Do we start with “As a <type of user>?” or should we start with “In order to <achieve some value>?”

In short, these people want to know how to write user stories effectively, which is a valid question. However, usually with some probing what I uncover is that they’re expecting to use the written user story to communicate the need, which is not a recommended practice. Continue reading

A 5th statement in the Agile Manfesto?

I’m going to make a bit of a radical proposal here. I propose that we add the following to the Agile Manifesto:

We value interpersonal skills over technical knowledge

I’m not really proposing that we change the manifesto. I’m also not stating that technical knowledge is not extremely important. Remember that the Agile Manifesto states that we value the things on the left more than the right, but we still value the things on the right. I’m just making a point that I think a lot of organizations miss that affects their ability to really get the most out of Agile and Scrum.

Continue reading

Why leadership loves agile in theory but sometimes hates it in practice

One of the most common myths about Agile and Scrum is that it’s something that only affects the developers. People, in particular executives and directors, believe that undertaking an Agile transformation means project teams change the way they work together and the rest of the organization just reaps the benefits. While this may be true in the short term, it’s often leadership and management that have to make the biggest changes for Scrum to be successful.

I was inspired to write this post after a chat with a friend who works in an organization that has been using Scrum for a few years. He told me that it didn’t take long for the weaker leaders to struggle as the organization adopted Scrum. He also said that the changes to how teams worked and were led created natural leaders who stepped forward and took the reins, sometimes even people no one expected.

I’m going to explain this with a rather facile example. Continue reading

When to use User Stories, Use Cases and IEEE 830 – Part 3: Requirement Statements

Requirement statements that begin with the phrase “The system shall” are often referred to as IEEE style statements, because they were recommended  for specifying software requirements in IEEE standard 830, and still are in 29148:2011.

The IEEE standard for software requirements specification recommends this method as they have many advantages  Continue reading

When to use User Stories, Use Cases and IEEE 830 – Part 2: Use Cases

I find use cases extremely valuable for eliciting requirements. Focusing the discussion on the business process with an informal use case, where each step is simply a bullet point and we don’t worry about using correct use case terminology, makes it much easier to keep conversation on track and productive and helps clarify and avoid misunderstandings that often occur between stakeholders and development staff in requirements discussions. Continue reading

When to use User Stories, Use Cases and IEEE 830 – Part 1

A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.

Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project. Continue reading

Agile and the Analyst

I recently took the Scrum Master course and certification. If you work in software development in any capacity and you have the chance, I recommend you take this course, even if you aren’t a proponent of Scrum itself. Approach it with an open mind and you’ll come away thinking a little differently about managing people. I’m not saying you’ll be an Agile convert, but it will make you re-examine lot of the fundamental assumptions of traditional project management.

As a business requirement specialist, I was particularly interested to see how an experienced analyst might fit into Scrum. I had read a couple of books on Scrum, Kanban, and other Agile topics but I found them somewhat vague when it got to Continue reading