In the third part in my series on user stories (Part 1 here, Part 2 here) will briefly cover some points on estimating user stories.
“How big should a user story be?” “What’s the difference between an epic and a story?” “How do I estimate the size of a user story?” “How do I know when a story should be split?” “How do I split stories?” When I first started working with user stories, I had these questions and Continue reading
Using stories effectively is a topic regularly asked about and discussed in forums, training and when coaching. It’s a big topic, however, that I can’t really cover in detail in a blog. Instead, I’ll provide my top 5 tips with some explanation for each. Continue reading
I’ve written previously about user stories, and I have compared them to other requirements techniques. Since then I’ve used them and seen them used in many new ways, some successful and some less so. I also often see people asking how to best use them, create them, develop them, size them and so on. I decided to dedicate a short series of blog posts to user stories.
The first, this one, will discuss common misunderstandings. Please at least skim it before reading the rest! After this post, I will provide some guidance on how to get the most out of user stories. The last in the series will discuss a very common question – how big is a user story?
But first, lets get some very common misconceptions about user stories out of the way.
This is 100% false. Continue reading
I was recently asked what to do when a stakeholder or client asks for a feature or user story that either doesn’t make sense or is based on flawed logic or on a lack of technology or domain knowledge. Sometimes stakeholders’ pet projects, wacky ideas and whims and fancies can be the nemesis of a product owner and her team. They waste valuable time and resources and in some cases they can affect team morale, as the team feels that they are on a fruitless errand.
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
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
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
