After a few sprints, the product backlog can look a lot like my family’s refrigerator. It’s stacked full. Some items are out of date. I don’t even know what’s in some of the containers. And I don’t know who put most of the stuff in there.
The storytime workshop is the CRM team’s opportunity to get together in the kitchen and clear out the fridge.
Backlog grooming sessions and backlog refinement meetings are other terms for a storytime workshop. I prefer storytime because it reminds me of my happy days at pre-school.
Format for the storytime workshop
I find it helpful to run a 45-minute workshop split into three sessions:
- Front of the fridge: take a look at stories near the front and top of the refrigerator – the stories that might get used in a recipe in the next three sprints. Refine those stories by making sure they all have good titles and descriptions, accurate user roles, and complete acceptance criteria. Take an action away from the workshop if you need to get more details about a requirement.
- Back of the fridge: take a look at the stories way down at the bottom and at the back of the refrigerator. Clear out any duplicate or redundant stories. Spend a moment improving any stories with missing descriptions or user roles.
- Don’t forget the freezer!: A useful practice, which I borrowed from Pivotal Tracker, is to have an icebox — a container separate from the backlog for new and un-prioritised items. At the storytime workshop, clear out your icebox by transferring useful items to the backlog or throwing them directly into the trash.
If your backlog is a complete mess (a form of technical debt) then don’t try and run a long storytime workshop to clear it in one go. Instead, hold several short workshops during the next sprint or two until all the clutter is gone.
Who participates in a storytime workshop?
You don’t need all the CRM team members to hold a storytime workshop. Storytime workshops are often held mid-sprint when most of the team are busy developing features. The Product Owner needs to attend, along with any subject matter experts with detailed knowledge of the requirements, and as many of the CRM team as possible.
If you do manage to get the entire team together, even for a few minutes towards the end of the workshop, it’s a good chance for a quick game of planning poker to estimate any stories that might be prioritised in the next few sprints.
How does your product backlog look? Do you have any other tips for clearing it out and making sure it doesn’t get filled with clutter? I’d love to hear your ideas in the comments below.
If you’ve ever waited until the end of the sprint to demonstrate a new feature to the product owner you might have had similar feedback to me.
“The address lookup is great, but isn’t there a way we could autocomplete addresses from an address validation service?”.
It can be a little frustrating when sprint review meetings are the moment for the real acceptance criteria to emerge. But it’s the end of the sprint and we haven’t got any time to incorporate any feedback, even tiny suggestions.
The story has to be accepted or rejected. Now.
We are often forced to compromise. We encourage the product owner to accept the story as-is because it meets the acceptance criteria provided at the start of the sprint. And we use the new acceptance criteria to create a new story to hopefully refine the feature later.
It was my friend, Isabel Gilad, who started arranging sneaky side sessions to present new features to Beth Cozza at Advantage Sales & Marketing. Before the end of the sprint! The features hadn’t been tested or documented.
Isabel’s stories were complete but weren’t done. But it worked.
Beth welcomed the opportunity to see features before they were done; while she still had a chance to amend the acceptance criteria. And Isabel loved the opportunity to deliver a better feature by the end of the sprint.
Isabel called them NFF: new feature feedback sessions. I call them story previews.
Five story preview best practices for CRM projects
Here are some tips for getting the most out of your story preview sessions:
- Make sure your product owner, or their delegate, is going to be available for some mid-sprint story preview sessions. Ideally, schedule your story preview times during the sprint planning meeting. Have an idea of which stories should be demonstrable at each preview.
- If you know your feature is going to be previewed, don’t finish the feature testing or documentation until after the preview.
- Bring another team member with you to the story preview. Ideally, bring the person who is going to test and document the feature before the end of the sprint.
- Agree on any new acceptance criteria and add them to the story and let the team know before or during the next daily standup.
- In the story preview, don’t commit to incorporating all feedback during the current sprint. Tiny changes might be OK, but there are often unintended consequences of small changes that you miss and other team members might notice.
What if feedback changes the story’s estimate?
If you are the team member that owns the story then you should be able to make the call whether you can incorporate the feedback into the story within the current estimate. But other team members will also have tasks related to your story too. If the preview feedback causes you to take longer to develop the feature, it’s not fair to squeeze the time for their tasks.
If your sprint has a little slack that will allow you to deliver a better feature within or very close to the original estimate then go ahead. But if the feedback added a couple of new acceptance criteria and you think the 5-point story now looks more like an 8-point story then you’ll need to add a new story to the backlog.
Whether you can incorporate the feedback within the current story estimate or you decide to create a new story to refine the feature later, make the decision as a team. Involve the Product Owner, Agile Coach and your other CRM team members so that everyone is on board.
Have you had success with story previews? I’d love you get your feedback about getting feedback in the comments.
Sprint planning workshops are the first event in each sprint of your CRM project.
The purpose of the sprint planning workshop is to:
- Set a sprint goal to provide a unifying theme to the stories that will be delivered during the upcoming sprint.
- To confirm the priority and acceptance criteria of the stories the Product Owner would like the CRM team to work on.
- Estimate the size of the stories and determine the tasks required to completed each story.
- As a team commit to the stories that will be delivered by the end of the sprint.
Sprint workshops cover a lot of ground. Often too much.
I want you to have highly productive, energising and helpful sprint planning meetings in your CRM projects, so here are some of my CRM sprint planning tips that I hope will help you.
When to schedule sprint planning meetings?
I recommend scheduling sprint planning workshops for two to three hours every other Tuesday afternoon. Wednesday and Thursday work well too. Mondays are often disrupted by public holidays and team members taking a long weekend. Fridays are similarly disrupted. I’ve found scheduling mid-week sprint planning workshops works best. Run the sprint review meeting for the previous sprint before lunch and the sprint planning workshop for the next sprint after lunch.
If you’re delivering consulting services for a client then timesheet and invoice systems hardly ever work well for sprints that finish in the middle of the day and the middle of the week. You might have some extra project accounting work to do. But it’s worth it.
Refine stories before sprint planning
Your product backlog should already be in pretty good shape if you’ve been running storytime workshops during your sprint. Stories near the top of the backlog should already be well defined and well understood by most of the CRM team. All the stories near the top of the backlog should already have acceptance criteria. If you’ve had most of the CRM team involved in storytime workshops you might even have estimates for a lot of the higher priority stories.
However, if your backlog still looks like as much of a mess as my family’s refrigerator then your product owner will have to spend additional time during the sprint planning meeting to add acceptance criteria and explain each story to the team.
Repeatable agenda for sprint planning
Here’s my starting agenda for sprint planning meetings. Try this, adapt it to suit your project, and please leave some feedback in the comments about what works or doesn’t work on your CRM projects.
- Product owner sets the sprint goal
- The whole team selects stories that support the goal
- Play planning poker
- Earmark stories for the sprint
- Produce sprint backlog
- Play fist of five
- Commit to stories for the sprint
Set sprint goals that are easy to communicate to all your stakeholders
In the best sprints, the product owner sets a unifying sprint goal that provides a theme for the sprint’s stories. This could be based on a business process or a user role. At American Homes 4 Rent we had several sprints focused on aspects of automating the lease renewal process with sprint goals such as Renter Communications, Lease Document Generation, and Electronically Signed Leases. This provided the CRM team and the property management team with clear expectations and a focus for the next two weeks that was easy to communicate to all the stakeholders at AH4R.
Select the stories that advance CRM towards meeting the sprint goal
Now that you have a clear goal for the sprint, the whole team should identify the stories that will enhance CRM toward meeting that goal. The selected stories don’t have to be those at the very top of the backlog. You might select 10 from the top 25 stories because they support your sprint goal. You might select some lower-priority stories just because they are technical precursors to higher-priority stories. The final choice is a joint decision of the whole project team: the Product Owner and CRM team.
Play planning poker to estimate complexity
I highly recommend playing planning poker as a team to estimate the complexity and effort of each story. Planning poker is easy to learn but can be difficult to master. It’ll take your team several sessions before you’re playing at pace but it delivers far better estimates and team commitment than having one person estimate stories on their own.
Earmark stories for the sprint
Based on your historical velocity check whether all the stories you’ve earmarked for this sprint can be delivered. If your average velocity for the last three sprints has been 40 points and you’ve estimated stories totalling between 35 to 45 points then proceed to the sprint backlog, otherwise you might need to include or exclude a couple of stories.
Produce the sprint backlog
I find that the easiest way to produce the sprint backlog is to write a sticky note for each story and arrange them vertically on the wall. Create another sticky note for each task required to complete the story. Short task titles are usually sufficient: Configure asset entity, Write forecast plugin, Install editable grid add-on, Write and execute tests.
Estimate the number of ideal hours’ effort for each task. Usually, I’ll accept the first estimate given by someone in the team as long as everyone is actively participating. I try and create tasks that each take about two hours. Some are one hour, some are three hours. But two is the default and we estimate more or less from there.
Total the number of ideal hours for each task, roll the effort up to get a total for each story and roll up again to get a total for all stories in the sprint. It should be close to the total number of working hours for the team during the sprint.
Play Fist of Five to gauge the team’s ability to commit
Fist of Five is a quick game to determine a team’s comfort with a decision. In this case, we play it to ensure everyone’s comfortable committing to delivering these stories in this sprint.
Hold your hand behind your back. Arrange to show between one and five fingers then reveal your hand at the same moment as everyone else. If anyone is showing less than three fingers then the team is unable to commit to the earmarked stories and needs to agree on an alternative course of action and play again until everyone’s holding a three or higher. The alternative course of action is usually to commit to all the earmarked stories except one and agree to re-introduce it if time permits.
Commit to the stories for this sprint
Once everyone in the team has agreed you can announce your committed stories to the product owner and other stakeholders. Now you can finalise your sprint backlog board and set up your sprint burndown chart and get going. Good luck!
When Ken Schwaber and Jeff Sutherland presented the Scrum agile framework in 1995, they borrowed the word scrum from the 1986 HBR article ‘The New New Product Development Game’ by Takeuchi and Nonaka. Nonaka and Takeuchi used the term scrum in a terrible analogy between rugby and new product development.
I’m guessing that Schwaber and Sutherland had more experience playing Dungeons & Dragons than rugby. How else would they have arrived at such a lame name: Scrum Master? Does that job come with a pointy hat and a wand?
(For the record, I was a Dungeon Master at the Irish and European role-playing games championships when I was a kid and was a winger for Edinburgh Northern 1st XV).
There’s definitely a role on an agile CRM team for someone to mentor the stakeholders and the team on the principles and practices of agile software implementation, and to guide the team toward maximum velocity. Let’s just call it at Agile Coach.
Role of the Agile Coach
The Agile Coach serves the Product Owner, the CRM team, and the consulting firm and the customer in different ways.
The Agile Coach serves the product owner by helping him or her envision the features that will have the most impact and providing backlog management coaching.
The Agile Coach serves the team by facilitating sprint events, helping the team find and adopt practices that maximise the value they deliver and by removing impediments to the team’s progress. The Agile Coach ensures the team doesn’t over commit to too many stories in a sprint; a good coach ensures they are not becoming complacent either.
The Agile Coach serves the consulting firm by mentoring the CRM team’s resources. They also serve both the customer and the consulting firm by managing risks and issues, and looking after the project’s budget.
Do we need a CRM Project Manager?
There is also a role for someone to perform the traditional project manager responsibilities in CRM projects performed by a consulting team for a client.
Lots of Scrum purists reject the notion of traditional project management. I agree with them that the Agile Coach’s role is not to produce project plans or to assign work to resources, but let’s agree that issue logs, budgets, and status reports are still useful artefacts on agile projects.
In a Customer Agility project, the Agile Coach also looks after risks and issues, budgets and resources and whatever project status reports are required by the client and the consulting firm.
In future articles, we’ll revisit the role of Agile Coaches on CRM projects and discover how they can really maximise the value created by the CRM team.
What’s your opinion on the Scrum Master role — are you more of a Dungeon Master or Scrum Half?
The CRM team are the people who implement the CRM platform guided by the vision and goals set by the Product Owner and the under the mentorship of the Agile Coach. It’s their role to analyse the requirements, the design, configure, customise, and test features that meet those requirements.
How many team members should be on the CRM team?
It doesn’t matter how many team members your CRM team has, as long as the team has all the skills needed to implement the CRM system.
When I implemented a Microsoft Dynamics CRM system for medical asset management at Guy’s Hospital, I was the only person in the team for several months before Greg Owens joined the project. (This was a few years before he became a famous racing driver.)
When I was the Agile Coach for the Salesforce Sales Cloud implementation at Red Bull, Tiffany Chen was the CRM team.
So really small teams can work.
How about bigger teams? What’s the upper limit?
Communication becomes exponentially harder with every additional team member you add.
If you are nervous at the daily standup that you miss your turn because it takes too long for everyone else to quickly check-in then your team is too big.
If you can’t remember what stories the team worked on in the last sprint then your team is too big.
I’ve found that about seven or eight team members is usually about the limit.
At American Homes 4 Rent, we split the program up so that we had separate teams working on the CRM platform, the website, business process improvement, and the data integration platform. At one point we probably had 30 consultants involved, but the core CRM team was never bigger than ten people.
What roles do CRM team members have?
Scrum says that team members don’t have titles. They might have areas of specialisation but that the team is collectively accountable for achieving its goals.
In my agile CRM projects, I’ve found that team members definitely tend to retain their area of focus. Analysts analyse requirements, architects design solutions, functional consultants configure features, developers develop custom code and integrate systems, and testers invent new acceptance criteria.
But after a few sprints, the team members have an appreciation for each other’s skills and become attuned to how other team members work. Analysts write better acceptance criteria, architects design simpler solutions, functional consultants and developers build features that are easier to test, and testers work in parallel with other team members to ensure better quality releases.
Great teams share tasks
In the best CRM teams I’ve worked with, team members often assigned themselves to a task that was outside their area of specialisation. This has lots of benefits for us as team members:
- We broaden their skills so we become more useful to the team
- We improve velocity by removing resource constraints
- We become better at our own area of specialisation by learning how our usual work impacts others
- We expand our knowledge of the system so we don’t become reliant on a single team member
Can a business analyst really develop custom code? Usually not, but they can help a developer with a code review. Even if the analyst doesn’t understand every method being explained, often the simple act of explaining the code’s design aloud to someone else will help the developer enhance the quality of his or her own work.
Great teams uphold agile principles
Great teams uphold the agile principles of commitment, courage, focus, openness and respect.
They are committed to the project and to the team’s goals. They are courageous enough to tackle tough challenges with bold solutions. They focus on the CRM project without distraction. They are open with each other and with all the project’s stakeholders. They show respect for each others’ contributions.
Think about the best agile CRM projects you’ve worked on? What qualities did they have tat made them special. I’d love to hear your comments below.
A sprint is a time-boxed iteration of software development during which we analyse, design, develop and test working CRM software based on the highest priority items in the product backlog.
How long is a sprint?
In Scrum, sprints can be between one week and one month long.
In the Customer Agility framework, I recommend a two-week sprint for CRM projects. Two weeks is enough time to get enough valuable features developed, but not too long that we miss out on frequent feedback.
Starting a sprint every other week seems to fit most stakeholders’ schedules. A two-week cadence seems to feel right for a lot of people.
Use one-week sprints with caution. If you’re running one-week sprints, you’ll need to run your sprint events efficiently so that they don’t consume too much of your sprint. You can’t afford an all-day sprint planning meeting in a one-week sprint.
Three-week or four-week sprints can be used for much larger projects when you are working with large teams. But longer sprint cycles means more time between feedback sessions so use with caution.
When should a sprint start?
I recommend starting a sprint with a sprint planning workshop scheduled for a mid-week afternoon. We finish that sprint with a morning sprint review meeting two weeks later. I run them as back-to-back meetings with a lunch break and the retrospective workshop in between.
Why start mid-week? Starting a sprint on a Monday is frequently disrupted. Public holidays often occur on Monday in many other countries or team members like to take Mondays as time-off. Monday sprints can also encourage some weekend overtime to finish a feature. Hardly anyone spends the weekend working when your sprints end in the middle of the week.
Can I use Sprint 0 to launch my project?
Some teams like to launch their project with a “Sprint 0” (Sprint Zero). They use this period to run some workshops and prepare the initial product backlog. Some teams also like to use Sprint 0 to get set up: provision the CRM development instance, prepare their development tools and their shared project workspace.
These preparatory activities all need to get done. But let’s not confuse prep work with delivering value. A sprint needs to deliver CRM software. I recommend calling your sprint 0 a planning, preparation or initiation phase and then starting sprint 1 once you’re ready to start delivering stories.
Can I change the sprint length?
At Advantage Sales & Marketing we changed the sprint duration from two weeks to three after about a year. The team seemed to prefer the three-week cadence, but I missed the regularity of sprint reviews every other week.
So it’s possible to change the sprint length, but I would not recommend it. The biggest downside is that changing the sprint length throws your cadence out of whack. Your historical velocity becomes meaningless and other metrics are harder to track too.
Should a sprint ever be extended or aborted?
A sprint is a time-box and it can’t be extended. Even when you just need a few extra days to finish a couple of big stories or there was a public holiday for two days in the middle of the sprint. Stick to a regular cadence.
Occasionally, you might need to abort a sprint. I used a one-week sprint cadence on a recent project that was four weeks long. But we had to abort sprint 2 because the product owner couldn’t match the team’s pace. Towards the end of sprint 2, we still couldn’t start half the stories. So we paused the project for a week to give the product owner some time to refine some of the stories. We resorted to stretching the same effort over two-week sprints giving the product owner time to commit to the sprint events and still perform her marketing job.
Your sprint experience
I’d love to hear about your experience working with different length sprints in your CRM projects. What’s length worked well and what didn’t? Have you ever changed the regular sprint duration in a project or had to abort a sprint? Leave me a comment below.
Customer Agility’s pillars and principles are based on the same values that underpin Scrum and the Agile Manifesto. Embracing agile’s core values is more important than perfectly adopting any of the practices.
In this article, we’ll explore the pillars and principles in a little more detail and share some examples of the core values in practice.
Core pillars and principles
Customer Agility has three pillars: transparency, inspection, and adaptation.
- Transparency. Our requirements, progress, and issues are all out in the open.
- Inspection. We frequently inspect what we’ve built and how we built it.
- Adaptation. We frequently adapt what we’re about to build and how we’ll build it.
Customer Agility also embraces the core principles of commitment, courage, focus, openness, and respect.
- Commitment. The CRM team commits to achieving the customer’s goals.
- Courage. We have the courage to solve tough problems.
- Focus. We focus on the work of the CRM project.
- Openness. Our communication is open and honest.
- Respect. The team members respect one another’s professionalism and ability.
Transparency should be a defining characteristic of an agile CRM project. In the spirit of transparency, we should be providing information about our project so it can be observed by any stakeholder. This can include:
- Publishing our story map and release plan for everyone to review
- Providing all stakeholders with access to review our product backlog
- Pinning our sprint boards and burndown charts to a wall where everyone can see them
- Inviting all stakeholders to our sprint review meetings
- Letting everyone know about the current state, recent progress (and setbacks) and future plans for the project in our internal communications
I like to use a wiki in my CRM projects, usually Atlassian Confluence, where we publish our story maps, release plans, backlogs, retrospective notes, and sometimes videos from the latest sprint reviews. The project’s burndown charts are also published on the wiki so that any stakeholder can visit the wiki site at any time and see where we’re at.
Maintaining the wiki is a team effort. Sometimes, if we’re lucky, there’s someone from a project management office who helps provide guidance so that project wikis are consistent and best practices are shared across other projects.
Inspection and Adaptation
Inspection and adaptation are part of empirical process control and the scientific method. By adopting these pillars we are acknowledging that it’s impossible to know all our requirements at the outset of the project. We admit that we cannot design the perfect solution before we start to build it.
Empirical process control is the opposite of defined process control. With defined process control we always get the same output given the same set of inputs. There’s very little variance.
Given all the variables in a CRM project, we can’t rely on the same set of outputs given the same set of inputs. We need to do some work, inspect the outputs and be prepared to adapt our next unit of work. We need frequent feedback.
Customer Agility’s events provide lots of opportunity for inspection and adaptation. Each event inspects a smaller scale piece of work. They are release planning, sprint planning and reviews, retrospectives, story previews and daily standups.
If your team finds itself skipping sprint review or retrospective meetings then you’re not giving yourself the opportunity to properly inspect and adapt the CRM system or your way of working.
Customer Agility projects require a commitment on several levels:
- Commitment from each team member to the project’s goals.
- Commitment from each team member to each other to work together as a team.
- Commitment from the team as a whole to work together to achieve the goals of each sprint.
When I’ve worked with high-performing agile CRM teams, commitment has expressed itself through several examples:
- A team member taking on a task that doesn’t play to their usual skills in order to meet the team’s commitments for the sprint.
- Team members organising their schedule and any other project work so that they can always attend the Scrum events.
- A team with spare capacity completing an extra story in the sprint that amplifies the achievement of the sprint goal.
Customer Agility projects aim to improve our customers’ experiences through digital transformation. We do this not because it is easy but because it is hard (to paraphrase a fellow Irishman). The most impactful projects are not the easy ones with reasonable goals but the challenging projects with ambitious goals.
A challenging project doesn’t mean it has an unrealistic timeframe or half the resources it needs. That’s not ambitious. That’s reckless.
A challenging project has lofty goals that will revolutionise organisational performance even if we’re not sure how to achieve those goals at the start of the project.
Courageous CRM teams set ambitious project and sprint goals. They work on risky features early in the project. They aren’t afraid to experiment with new techniques and ideas. They aren’t afraid of feedback from CRM users or real customers. In short, they are not afraid to fail. But when they do they fail fast.
The hardest agile CRM projects I’ve worked on are those where I’m also working on something else. You’ll always perform your best work given the opportunity to focus on one project. Distracted by a second project or support work for another team and you’ll lose focus.
There are several advantages to being able to focus on one CRM project at a time. You’re always available just at the moment when your skills are needed so the team isn’t stuck waiting for your focus to return. There’s also an intellectual focus you can achieve when you only have one project to concentrate on and don’t have to mentally switch your brain into another context.
As far as you can, focus on one agile CRM project at a time.
Hand in hand with the team’s transparency to its stakeholders is each team member’s openness to the team. If you’re stuck on a task, behind on a story or struggling with a problem then let your team know. At the very least bring it up at the next daily standup but you don’t have to wait until then.
On my best agile CRM projects, I worked alongside talented team members that were always willing to share and declare any blockers. Even when it revealed a deficiency in our own skills. We knew the other team members had our backs and we’d learn something new as we figured out the answer together.
The spirit of openness is really only possible when you also have respect for your fellow team members. Trust them to be capable, talented individuals with a unique combination of skills that enriches the team. We respect the diversity of ideas and contributions because teams that all march to the tune of a single person underperforms over the long term.
I’ve been fortunate enough to work with lots of CRM practitioners on my agile CRM projects, maybe more than one hundred. They’ve all made a valuable contribution to the projects I’ve worked on, and I’m grateful to each of them.