This past week we’ve given away free online training and a number of resources to help you combat some of the most vexing problems agile teams encounter when writing user stories.
Now it’s time to open the doors to the full course: Better User Stories.
“In my 30 years of IT experience, this class has without question provided the most ‘bang for buck’ of any previous training course I have ever attended. If you or your organization are struggling with user stories, then this class is absolutely a must have. I simply can’t recommend it enough. 5 Stars!!” - Douglas Tooley
If you watched and enjoyed the free videos, you’ll love Better User Stories. It’s much more in-depth, with 9 modules of advanced training, worksheets, lesson transcripts, audio recordings, bonus materials, and quizzes to help cement the learning.
Registration for Better User Stories will only be open for one week
Because of the intense level of interest in this course, we’re expecting a large numbers of people to sign-up. That’s why we’re only opening the doors for one week, so that we have the time and resources to get everyone settled.
If demand is even higher than we expect, we may close the doors early, so if you already know you’re interested, the next step is to:
Choose one of 3 levels of access. Which is right for you?
I know when it comes to training, everyone has different needs, objectives, learning preferences and budgets.
That’s why you can choose from 3 levels of access when you register:
- Professional - Get the full course with lifetime access to all materials and any future upgrades
- Expert Access - Acquire the full course and become part of the Better User Stories online community, where you can discuss ideas, share tips and submit questions to live Q+A calls with Mike
- Work With Mike - Secure all of the above, plus private, 1:1 time with Mike to work through any specific issues or challenges.
What people are already saying
We recently finished a beta launch where a number of agilists worked through all 9 modules, providing feedback along the way. This let us tweak, polish and finish the course to make it even more practical and valuable.
Here’s what people had to say:
Thank you for an amazing course. Better User Stories is by far the best course I have had since I started my agile journey back in 2008.Anne Aaroe
Packed full of humor, stories, and exercises the course is easy to take at one’s own leisure. Mike Cohn has a way of covering complex topics such as splitting user stories with easy to understand acronyms, charts and reinforces these concepts with quizzes and homework that really bring the learning objectives to life. So, whether you’re practicing scrum or just looking to learn more about user stories this course will provide you the roadmap needed to improve at any experience level, at a cost that everyone can appreciate.Aaron Corcoran
Click here to read a full description of the course, and what you get with each of the 3 levels of access. Questions about the course?
Let me know in the comments below.
Today’s post introduces the third installment in a free series of training videos all about user stories. Available for a limited time only, you can watch all released videos by signing up to the Better User Stories Mini-Course. Already signed up? Check your inbox for a link to the latest video, or continue reading to find out about today’s lesson.
An extremely common problem with user stories is including the right amount of detail.
If you include too much detail in user stories this makes story writing take longer than it would otherwise. As with so many activities in the business world, we want to guard against spending more time on something than necessary.
Also, spending time adding too much detail leads to slower development as tasks like design, coding, and testing do not start until the details have been added. This delay also means it takes longer for the team and its product owner to get feedback from users and stakeholders.
But adding too little detail can lead to different but equally frustrating problems. Leave out detail and the team may struggle to fully implement a story during a sprint as they instead spend time seeking answers.
With too little detail, there’s also an increased chance the development team will go astray on a story by filling in the gaps with what they think is needed rather than asking for clarification.
There’s danger on both sides.
But, when you discover how much detail to add to your stories, it’s like Goldilocks finding the perfect bowl of porridge. Not too much, not too little, but just right.
But how do you discover how much is the right amount?
You can learn how in a new, 13-minute free video training I’ve just released. It’s part of the Better User Stories Mini-Course. To watch the free video, simply sign up here and you’ll get instant access.
Remember, if you’ve already signed up to the course you don’t need to sign in again, just go to www.betteruserstories.com and video #3 will already be unlocked for you.
Adding the right amount of detail--not too much, not too little--is one of the best ways to improve how your team works with user stories. I’m confident this new video will help.
P.S. This video is only going to be available for a very short period. I encourage you to watch it now at www.betteruserstories.com.
Today’s post introduces the second installment in a free series of training videos all about user stories. Available for a limited time only, you can watch all released videos by signing up to the Better User Stories Mini-Course. Already signed up? Check your inbox for a link to the latest video, or continue reading to find out about today’s lesson.
One of the most common struggles faced by agile teams is the need to split user stories. I'm sure you've struggled with this. I certainly did at first.
In fact, when I first began using Scrum, some of our product backlog items were so big that we occasionally opted for six-week sprints. With a bit more experience, though, that team and I saw enough ways to split work that we could have done one-day sprints if we'd wanted.
But splitting stories was hard at first. Really hard.
But I've got some good news for you. Not only have I figured out how to split stories on my own, I've learned how to explain how to do it so that anyone can quickly become an expert.
What I discovered is that almost every story can be split with one of five techniques. Learn those five simple techniques and you're set.
Even better, the five techniques form an easily memorable acronym: SPIDR.
I've just released a new, 20-minute, free video training that describes each of these techniques as part of the Better User Stories Mini-Course. To watch it simply sign up here and you’ll get instant access.
Remember, if you’ve already signed up to the course you don’t need to sign in again, just check your inbox for an email from me with a link to the latest lesson.
Unless you've already cracked the code on splitting stories, you definitely want to learn the five techniques that make up the SPIDR approach by watching this free video training.
P.S. This video is only going to be available for a very short period. I encourage you to watch it now at https://www.betteruserstories.com.
Today I want to let you know about a new mini-course I created to help overcome some of the common and challenging problems with user stories.
It’s free to register and you can access the first video instantly, or watch it a little later at your convenience. Once you do sign-up I’ll also send you an email to let you know as soon as the next video is released.
Please note: This training is free but will only be available for the next 2 weeks
Last year I did a survey to discover what challenges were stopping people write successful user stories. Nearly 2,000 people got in touch to highlight the following issues:
- Not writing stories that truly focus on the user’s needs
- Wondering how to keep a team engaged from writing to development
- Splitting stories quickly without compromising value
- Not knowing when to add detail, or how much to include
Plus many, many more. I wanted to create a mini-course that would tackle some of these issues, and I wanted to offer it to you for free.
Even though there’s no fee to access the videos, the training isn’t light-touch, an introduction, or theory-filled. It’s based on practical materials I’ve used for teaching user stories to more than 20,000 people over the last fifteen years. What’s more, you’ll also have the chance to comment, ask questions and discuss the training featured in each video.
To go alongside the launch of the mini-course, over the next couple of weeks, both the blog and weekly tips email will feature lessons and advice on how to write better user stories.
And if you really want you and your team to master this topic, there will be an option to unlock more in-depth, advanced training (details about that coming soon).
Today, get instant access to video 1: Three Tips for Successful Story Mapping in a Story-Writing Workshop
The first video is available now. This 20 minute training looks at some of the common mistakes people make at the early stage of writing user stories, particularly when conducting a story-writing workshop.
In this video you’ll learn:
- Why people struggle to find the balance between too much, and too little team engagement when writing user stories.
- How to save a significant amount of time in future iteration planning by inviting the right people to your story-writing workshop
- A simple, but powerful method of visualizing the relationship between stories
- Practical ways to make sure your team focuses on the user’s needs at all times
- Methods to help you prioritize and plan stories, fast
Questions about the training? Already watched the first video? I’d love to hear from you in the comments below.
Perhaps the most prevalent and persistent myth in agile is that a cross-functional team is one on which each person possesses every skill necessary to complete the work.
This is simply not true.
A cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills.Specialists Are Acceptable on Agile Teams
It is perfectly acceptable to have specialists on an agile team. And I suspect a lot of productivity has been lost by teams pursuing some false holy grail of having each team member able to do everything.
However, specialists can cause problems on any team using an iterative and incremental approach such as agile. Specialists make it hard to balance the types of work done by a team. If your team does have the world’s greatest database developer, how do you ensure your team always brings into an iteration the right amount of work for that person without bringing in too much for the programmers, the testers, or others?
To better see the impact of specialists, let’s look at a few examples. In Figure 1, we see a four-person team where each person is a specialist. Persons 1 and 2 are programmers and can only program. This is indicated by the red squares and the coding prompt icon within them. Persons 3 and 4 are testers who do nothing but test. They are indicated by the green square and the pencil and ruler icons within those. You can imagine any skills you’d like, but for these examples I’ll use programmers (red) and testers (green).
The four-person team in Figure 1 is capable of completing four red tasks in an iteration and four green tasks in an iteration. They cannot do five red tasks or five green tasks.
But if their work is distributed across two product backlog items as shown in Figure 2, this team will be able to finish that work in an iteration.
But, any allocation of work that is not evenly split between blue and green work will be impossible for this team to complete. This means the specialist team of Figure 1 could not complete the work in any of the allocations shown in Figure 3.
The Impact of Multi-Skilled Team Members
Next, let’s consider how the situation is changed if two of the specialist team members of Figure 1 are now each able to do both red and green work. I refer to such team members as multi-skilled individuals. Such team members are sometimes called generalists, but I find that misleading. We don’t need someone to be able to do everything. It is often enough to have a team member or two who has a couple of the skills a team needs rather than all of the skills.
Figure 4 shows this team. Persons 1 and 2 remain specialists, only able to do one type of work each. But now, Persons 3 and 4 are multi-skilled and each can do either red or green work.
This team can complete many more allocations of work than could the specialist team of Figure 1. Figure 5 shows all the possible allocations that become possible when two multi-skilled members are added to the team.
By replacing just a couple of specialists with multi-skilled members, the team is able to complete any allocation of work except work that would require 0 or 1 unit of either skill. In most cases, a team can avoid planning an iteration that is so heavily skewed simply through careful selection of the product backlog items to be worked on. In this example, if the first product backlog item selected was heavily green, the team would not select a second item that was also heavily green.The Role of Specialists on an Agile Team
From this, we can see that specialists can exist on high-performing agile teams. But, it is the multi-skilled team members who allow that to be possible. There is nothing wrong with having a very talented specialist on a team--and there are actually many good reasons to value such experts.
But a good agile team will also include multi-skilled individuals. These individuals can smooth out the workload when a team needs to do more or less of a particular type of work in an iteration. Such individuals may also benefit a team in bringing more balanced perspectives to design discussions.Evidence from My Local Grocery Store
As evidence that specialists are acceptable as long as they are balanced by multi-skilled team members, consider your local grocery store. A typical store will have cashiers who scan items and accept payment. The store will also have people who bag the groceries for you. If the bagger gets behind, the cashier shifts and helps bag items. The multi-skilled cashier/bagger allows the store to use fewer specialist baggers per shift.What Role Do Specialists Play on Your Team?
What role do specialists play on your team? What techniques do you use to allow specialists to specialize? Please share your thoughts in the comments below.
One of the foundational principles of agile and Scrum is a belief in the power of self-organizing teams. This makes a micromanaging boss, ScrumMaster or product owner a particularly difficult problem for agile teams.
I’ve found asking three questions helpful in dealing with micromanagers.Who?
The first question is Who? Who is being micromanaged? If you are being micromanaged but the rest of the team is not, this tells you it is your own performance that someone is worried about. If so, you’ll need to improve your own performance and that stakeholder’s view of your performance.
But if your entire team is being micromanaged, the behavior is just part of who that stakeholder is.
To determine whether it’s just you or your entire team being micromanaged, spend a sprint or two noting what types of things draw the micromanager’s attention. Log all micromanaging activities so you can look back at the data and determine who is being micromanaged.When?
A log of micromanagement activity will also help you answer the second question: When is the micromanaging occurring?
Does the stakeholder micromanage shortly before or after a meeting? For example, a product owner might leave their customer call every Tuesday feeling stressed and more inclined to micromanage. Or a Scrum Master might be prone to micromanage the day before the monthly meeting with the engineering VP.
Some people are more prone to micromanage at a specific time of day. A boss early in my career was particularly prone to micromanaging before his first cup of coffee.
Others may be more prone to micromanagement at specific times during an iteration. Perhaps the person you’re dealing with is most prone to micromanaging during the last few days of the iteration when he or she gets nervous about whether everything will get done. Again, log this type of information so you can later look for patterns.
I use a spreadsheet with the following columns:
Date: The actual date (e.g., March 8, 2017). This usually won’t help identify patterns but can be useful if you look back on the data and need to remember what might have been going on in the organization at the time.
Day of Week: Sometimes micromanaging occurs most frequently on certain days (e.g. Friday) so note the day of the week.
Day of the Sprint: To help see if micromanaging occurs most frequently at certain points within a sprint, note the number of days into the sprint when the micromanaging occurred. For example “Day 3” or perhaps “7 / 10” to indicate it occurred on day seven of a ten-day sprint.
Time: Note the time of day when the micromanaging occurred (e.g., 10:15 A.M.)
Who Was Being Micromanaged: Note whether it was you personally, the entire team, or perhaps a teammate being micromanaged.
What Was Being Micromanaged: Note the issue in this column.
Context: Note whether the micromanaging coincided with anything else occurring within the sprint, project or organization. Did it occur right before or after a meeting? Which meeting? What was occurring during the iteration overall?
Notes: Include anything additional worth remembering about the incident. You can see a sample in the following table.
Sprint Time Micromanager Who? What? Context Notes March 8 Wed 6
10:30Anne me Story about adding data sources
Anne asked me for the 3rd time in two days how this was going.
March 8Wed 6 2:15 Arie team Next week’s new client launch
Arie emailed the full team to remind everyone how important the new client launch is
Story about Salesforce integration
While en route to daily scrum, Anne asked me to tell Ashishto see her sometime about the story he’s working on for her.
Ashish has been providing her a daily update already as she requested.
After you’ve logged a couple of weeks of micromanaging activities, it’s time to ask the third question: Why is the micromanaging happening?
Scan your log looking for patterns. See if there are triggers that create the micromanagement. Perhaps your product owner micromanages you after her weekly meeting with her boss.
Perhaps your line manager is prone to micromanaging at the end of the month when he has to prepare a report for his boss.
Based on the patterns you see, try to identify conversations that may be worth having with whoever is micromanaging. You’re unlikely to get far by merely saying, “Please stop micromanaging.” Instead, talk to micromanagers in an attempt to learn what concerns them that they’re behaving as they are.
Once you’ve identified some of the triggers for micromanaging, it’s time to anticipate and eliminate those triggers.Anticipate and Eliminate
If you can anticipate micromanaging behavior by noticing when it occurs, work to eliminate the trigger. Often you can do this by proactively providing information to the micromanager.
For example, if you know your product owner gets stressed and micromanages after a weekly meeting with her boss, schedule a meeting with your product owner ahead of that meeting. Be sure your product owner is well informed and prepared for her meeting.
Proactively provide information to stakeholders who are prone to micromanagement. Try to do it just in time so they have (and remember) the information in advance of whatever triggers them.
Avoid creating burdensome new processes for yourself. But you can assert control over a stakeholder (or boss) relationship by proactively providing information rather than waiting to be asked for it and then being forced to provide it on someone else’s schedule.Some People Are Incurable
By following the advice here, you won’t always be able to eliminate micromanagement. Some stakeholders are incurable micromanagers. But the tips here will help you take greater control over most situations and generally make them more tolerable.How Have You Handled a Micromanager?
What’s your worst story of being micromanaged? How did you handle the situation? Please leave your thoughts in the comments below.
Get Your Free Micromanagement Log
Start tracking to help eliminate micromanagement
The most discernible activity during a sprint review is a demonstration of the functionality built during the sprint. But, a good sprint review includes more than just a demo. Let’s take a look at an agenda for the review.Welcome Participants & Set the Stage for the Sprint Review
The product owner starts by welcoming everyone to the sprint review. This can be as simple as saying, “Thank you for being here.”
If participants are unfamiliar with one another, the product owner may have attendees briefly introduce themselves. Introductions are generally a good idea at the start of a new product development initiative. The product owner knows that Joe from Marketing is Joe from Marketing but team members may not.
Introductions are also helpful if it is common for an occasional new participant to attend sprint reviews. Perhaps Joe from Marketing will only attend two reviews following the sprints in which the team worked on marketing-related features.
Introductions should be kept extremely short. “Hi, I’m Mike and I’m a developer. I’ve been working on the shopping cart features,” is plenty. In some cases, “I’m Mike and I’m a developer,” would be enough. But once a team reaches a certain size, it can be helpful for stakeholders to hear a few words to let them know who has been doing what.
After an initial welcome by the product owner and any needed introductions, the product owner can share any ground rules or expectations for the sprint review. For example, some product owners find it necessary to state the need to keep the meeting civil. If someone doesn’t like how a feature was implemented it’s fine to say so, but don’t call the implementation “stupid” or so on. Yes, we all should know things like this anyway, but sometimes people need to be reminded.
Depending on the number of attendees and many other factors, a product owner might also state that while she is looking for feedback on what was built, the sprint review itself will not be the time to redesign features.
With the welcome message, introductions, and ground rules out of the way, it’s time to move onto the next item on the agenda.State What Will (and Will Not) Be Demonstrated
At this point, many teams dive right in and start demonstrating. Instead, I recommend the product owner present a very brief overview of what will be demonstrated and what will not be.
To avoid a product owner just reading a list of items that participants won’t be able to follow, display something on the monitor or projector being used. Or have printed copies available for those who want one.
I like to prepare this as a Word document and email it to likely review participants at the end of the day before the review. This allows people a chance to see what will be demonstrated. Each person can then intelligently decide whether to attend or not based on what will be shown.
The following table shows the information I like to include for each product backlog item. I recommend putting this list in the order in which items will be demonstrated, although you can change that on the fly as needed during the meeting.
Description SIZE STATUS DEMO As a user, I .... 5 Finished
YesAs a user, I .... 3
Finished but there’s more we could add to the such-and-such part of this.Yes As a user, I .... 5 We started but there were too many open issues No Bug fix: Update the copyright notice on the About screen 0 Finished No ADDED: As a … 3 We brought this item in when we dropped the item above. Yes
The table starts with a description of the item. Put the user story or other description here. Next include the size of the item, usually this will be in story points. Then list the status of the item. Mostly this is whether the item was finished or not, but include anything else that is important to note. Finally, include a column indicating whether the item will be demonstrated or not.
You may wonder why we’d ever have items that the team would not demonstrate. I’ve provided a couple of examples in the sample table. Obviously, the item that was planned into the sprint but dropped cannot be demonstrated. I’ve also shown a simple bug fix that updates one character on one screen--it is not scheduled for demonstration either.
It’s quite possible that one or more participants might ask to see an item that you had not planned to show. When that happens, go ahead and demonstrate the item along with all others. You’re not trying to avoid showing something, you’re just trying to be respectful of people’s time by not showing them things that don’t really need feedback.
Notice in the sample above, I indicated that one product backlog item was added during the sprint. I think it’s a good idea to indicate items added during the sprint so they can be distinguished from those that were planned into the sprint. If adding items happens frequently, consider adding an initial column and putting P (for Planned) or A (for Added) in it.
You might also want to consider a column at the far right that can be used to indicate whether each item is accepted by the review participants or ready to release or such. Do this if those types of decisions are formally made as part of a sprint review.
Avoid spending too much time on this part of the agenda. The goal here is not to get feedback on the items or to talk about why a planned item was only partially implemented. This is merely a table of contents into the rest of the meeting. After the product owner has presented this list, move onto the main part of the sprint review: the demo itself.Demo New Functionality
This is the heart of the sprint review. And if you’re already doing sprint reviews, it’s quite possible this is the only part of the agenda you’re doing.
During this portion of the review, proceed down the list of items you’ve previously shown meeting participants. Keep in mind that the purpose of the sprint review is to solicit feedback.
There is no hard rule about who gives the demo. In some cases, a product owner will operate the keyboard. I’d recommend doing that in a review with particularly challenging stakeholders. Other times, though, team members will demonstrate the specific product backlog items they worked on. Just about any approach works fine. So experiment to find the one that works best for your team.Discuss Key Occurrences
After all completed product backlog items have been demonstrated, discuss key events or problems that occurred during the sprint.
This discussion could be facilitated by either the product owner or Scrum Master. I’ve found both approaches to work equally well. I do, however, have a slight bias toward having the Scrum Master conduct this part of the meeting.
Up until now, in most sprint reviews the product owner will have done a lot more talking than the Scrum Master. So I find it a good balance to have the Scrum Master facilitate this agenda item. Plus, this is often more a discussion of the process than strictly the product, and so it falls a bit more in the domain of the Scrum Master.Present Upcoming Product Backlog Items
The final item on a sprint review agenda should be a discussion of the next work on the product backlog. Because the purpose of the sprint review is to acquire feedback on the work of the current sprint, this will often influence what will be worked on in subsequent sprints.
If, for example, participants in the review liked the look of the new screens, the product owner may want to accelerate moving other parts of the product to the new design. Or, if participants didn’t like how a feature was implemented, perhaps the next sprint should be spent fixing issues with it instead of moving onto the next items, as might have happened without a sprint review.
The product owner starts this discussion by presenting the next set of potential items from the product backlog. The product owner might say something like, “On the screen, you’ll see what I thought would be our next ten things to work on, but I want to insert such-and-such that came up today. I’ll add that probably as item three.”
The product owner then solicits comments from participants about the proposed next set of items. I do not, however, recommend that the product owner make any prioritization decisions during the sprint review based on these comments. The reasons for this are many. The product owner may need time to think about what was said in the review. Or the product owner may want to get estimates from the team about changes that were requested in the review. And so on. Instead, the product owner solicits opinions during the sprint review and then makes decisions after the meeting.Conclude the Meeting
Simply wrap up by thanking everyone for participating. Consider thanking the team in whole for the work of the sprint. Consider occasionally praising a team member or two who performed exceptionally well during the sprint. Remind everyone when and where the next review will be held.After the Sprint Review
Although not part of the agenda for the actual review, someone should enter any new product backlog items into whatever tool the team is using (or post them on the wall if using physical cards).How Do You Conduct Reviews?
Please let me know how you do your sprint reviews. Do you include anything I didn’t mention? Do you skip some of these steps? Please share your thoughts in the comments below.
Get Your Free Sprint Review Agenda Poster