Lean Agile Training | Scrum Courses, Coaching, Consulting | US Canada.+Add.Feed Info1000FOLLOWERS
Scrum Courses, Consulting Coaching, Lean Agile Scrum Transformations-Agile Software Development, New Product Development, Project Management. Follow this blog to gain in depth knowledge on scrum and agile.
Let me propose an idea. I am happier if you call it a practice.
The idea is simple. That agreeing on what you are doing will help. Or, that not agreeing and only kinda sorta roughly trying to do [agile] is likely to lead to notably less-good results.
And I am not proposing a draconian “Thou must do Agile with absolute purity as defined by Gods 6000 miles away!”. Not at all.
But I am suggesting that by talking about it, thinking it through, and roughly assuming that people in roughly the same situation should do agile roughly the same way…..that that will help.
It will, especially, be less confusing to relative beginners (that is, those who have only been doing “pretty good” agile for 3 years or less).
It certainly should lead to some good discussions about “what is the best way to do things around here”.
OK, say you have a group of 50 people. Gather your 7 “best” people. Include some managers, some coders, some testers, maybe a ScrumMaster or two, maybe a Product Owner.
Note: I made some assumptions. You are doing software. And your firm is trying to be at least Scrum-ish. Also, this is not the only way to do this exercise.
OK, start defining agile for your teams.
Here’s what you might come up with. (Lots of really good discussion as you agree to each item. Agreeing on these might take some time.)
This is an example list. (For your specific situation, I might propose a notably different list. You must decide, although starting with standard things until you ghive them a good experimental try is not a bad policy.)
Agile Manifesto (4)
Agile Principles (12)
You have to go slow to go fast
Fail fast, learn fast
It ain’t over ’till its over (eg, a story must have zero bugs before done)
The bad news does not get better with age (it gets worse)
More honesty, more truth, more transparency
Minimal viable product. We’re shooting for 80-20. (80% of the BVPs can be done with 20% of the SPs.)
Increase Happiness metric.
Double Velocity in 1 year.
Quality (in every dimension) cannot go down.
WIP. Minimize Work In Process.
Single piece continuous flow. In the sprint, AMAP.
Team size = 7
Product Owner. 100%
Doers. Coders, testers. 100%.
Managers and team agree team set up for success, enough
Business stakeholders (BSHs) – 4 people. 15% available. Right people. Will attend every Sprint Review. Are appropriate to give fast and complete feedback on details in Sprint Review (or will bring a SME).
Chickens. Always identified at beginning of project. Team thinks they are set up for success
Sprint length = 2 weeks
Always do a Low Grooming (aka pre-planning) meeting before SPM. All stories “good to go” per Team based on Ready-Ready Criteria. All stories small, about same size, and at least 8 stories. All stories have SPs (before going into SPM)
Sprint Planning Meeting. BSHs attend first part. Max 4 hours total. All tasks less than or equal 4 hours.
Daily Scrum. Less than 15 mins. No disruptions. Team feels this enables them to self-manage toward success. (That is, the meeting is for them.) SM and PO also answer 3 Q’s. Everyone is honest. People help each other. Everyone admits to a biggest impediment. They even say “I sucked yesterday…. because I don’t know how to do that kinds stuff in Java.”
After-Meeting. Usually we have an after-meeting (after the DS). And ~3 people stay to discuss biggest impediment
Sprint Review. 10 min Review. Mostly Demo. Roman voting by all. Most discussion is about those that are “close”, which must be fixed next sprint. Cheers when everyone is thumbs up on a story. All BSHs attend and are useful. Virtually zero “I will get back to you on that”
Retrospective. Whole sctrum team attends. Short bitching and moaning. Short SM report (has to show some results). Expect improved Velocity each time. Mainly work together to fix top impediment
High Grooming Meeting. Team meets to break down stories and re-org PBL based on new info (eg, new SPs and new BVPs, or new stories)
Product Backlog (PBL). Goes out 6 months. Mostly stories. Everything in current release must be “sprint-sized” (8+ stories in each sprint). Stories in at least 1st and 2nd releases have SPs.
Ready-Ready Criteria. We have them. We know how to use them. The Team feels like they are set up with all the info they need to be successful
Sprint Backlog (SBL). Stories and tasks
Scrum Board. SBL becomes Scrum Board. Backlog, In Process, To-be-tested, Done. A kind of flow in a Kanban Board. Visible to all in the Team Room
Sprint Burndown Chart. Team updates data daily. Team uses it to self-manage
Release Burndown Chart. Team upfdates data each sprint. Team uses it to self-manage
DOD. Definition of Done. Stronger now. Zero bugs, more testing
Working product. Almost always all the stories are potentially shippable product increment by the end of the sprint
Impediment List. The top 20 impediments as of now. If we fixed a half or third of them, we would double velocity
Business Value. [Should be several metrics, and they vary a lot. We’ll give one example now that fits some situations.] Within 6 months, we expect unique visitors to increase 20% as a daily average over a week
Business Value. We will use BVPs (voted by our experts, the PO and BSHs) to improve BV delivery
Velocity. Average over last 3 sprints. Expect to double within one year at least. (Do not expect as much improvement once they get to 5x of initial baseline.)
Happiness metric per Jeff Sutherland
Quality. Adhere to new coding and technical standards. Goal: Zero bugs escape the sprint. Legacy bugs: reduce by 5% per sprint. Legacy bug list to zero within 20 sprints
Hours. No more than 45 hours per week. No over-working at home; minimal working at home
Key Execution Points
Stable team. We work hard to motivate the Team and keep the Team together and stable
Real Team. The Team will be better if they all commit. Help each other. Become more multi-functional. No one is equal, but everyone can contribute. “All for one and one for all.” The magic of the Team cannot be clearly explained
Motivation. Autonomy, Mastery Purpose. PO expected to inspire the Team (AMAP)
Team Room. Most teams will be collocated. Collocated teams will have a Team Room. Team members expected to be in Team Room > 4 hours per day
Self-manage. Team is responsible for full success. Full success with everything considered. And to act like adults and use common sense
Ask for help. Team is expected to ask for help on some things
Fail Fast. Team is expected to make mistakes and learn from mistakes. Faster
Changing Plan. The plan MUST change every sprint. More accurate. In general, we want the plan to become better AMAP, that is, usually “deliver less sooner”. Like Lean Start-up; learn and pivot
Managers. Servant leaders. Managers are essential. Can offer help. Must intervene if team will fail. Usually encouraging the team to self-organize and self-manage. A (local) Manager manages 4 teams
Budget for Impediments. Every team gets 10% of team cost to spend to fix impediments. We expect at least a 3x return on that investment. Team and (local) manager are responsible for ROI on that investment over year
Higher innovation. A key goal is faster learning and higher innovation. We ssume all of us must work together to make that happen
Customers. We assume the customer feels the pain. We assume that customer is usually bad at diagnosing the root cause. We assume the customers are usually bad at identifying the root cause problem. The customer (with our persuasion) is the final authority on whether the problem was fixed the right way. The customer prefers something now rather than a LOT later. Delivering something wrong now is better than delivering something “perfect” later. The bad news does not get better with age
Shut-up and Drive. The worst decision is no decision. Better a wrong decision now than wait (endlessly) for a perfect decision. BUT…a few decisions deserve careful thought.
We want emergent leadership
Delivered BV faster is more important than efficiency of each team member. We must have some slack to get speed
This is an example list.
Your list will be different. First, you might want to take this and make it better or more. Or different and maybe less. Also, often they won’t agree to it — better to get them to agree and then do it. Then make it stronger later.
Second, your situation is different, or where your team is now is different. So, this list might be inappropriate, at least in part. Or, as suggested earlier, the politics of getting them from where they are to a specific place would be too hard.
BUT, they will have agreed on some list.
Was that list implemented in a draconian way? No. They agreed to it.
In your larger group, there is at least the possibility that one or more teams is special. A specific team needs something different or at least a bit different. You must have a way to accommodate these difference, without letting down standards completely.
Let’s be fair. Some of these things I proposed will cause some people to push back. They will see it as a threat, they will object to the transparency, they will feel threatened. And they (some of them) will just not understand (yet).
Still, some of the push backs will likely to be fair and appropriate.
So, have a small group of people (agile coaches) who deals with each special case. If the proposed changes are ill-advised, the reviewers try to talk the team out of it. And the reviewers can make some changes legitimate (as well they may be).
If you implement this, it is work. But it will help.
And “agile” will not be just a tick box.
I think this will lead to great conversations that enable the teams to get more benefits from lean – agile – scrum.
But let’s agree that things can be a bit more complex.
There are many different kinds of situations in Scrum. We have Continuous Delivery (aka CD) now. Scrum still helps in that situation, but it is different.
We also have people releasing every sprint into production.
The word “release into production” is fairly commonly used in software. It is probably less commonly used for other products, and we think Scrum is also very suitable for any new product development. So, if you use different words, please translate.
So, if CD or releasing every sprint, the concept of a release burndown chart is not meaningful. The concept of a “product burndown” might be.
So, assuming you are taking 2 sprints or more to product a product (6 is a fairly common number to use as an example), then why do we want a release burndown chart?
Two reasons come quickly to mind.
One is to measure progress. If we start at 120 SPs of work and get down to 60 SPs, then we are in some sense 50% done.
Why is that useful? Because I think it gives us the transparency to “take arms against a sea of troubles, and by opposing, end them”. It makes us cut through the crap and get stuff done. On time.
It keeps managers from canceling projects that have made significant progress. (That has been done to waterfall projects, unfairly.)
So, I am suggesting that the common (not universal) practice in Scrum is to (eventually) set a date. We have a stable team, and therefore budget is fixed. And the flexible part is scope (or “how many stories will we get done in the timebox?”). Another flexible part is “how much will the SM raise the Velocity of the team?”
Here an example picture:
[Picture to be added.]
One axis is story points, or the total of the SPs for all the stories that are “remaining”. We are measuring “work remaining”. The other axis is time, divided into 6 sprints. So, we measure work remaining every sprint. And get transparency on that.
Side note: One of the purposes of the Release Burndown is greater transparency (this benefits many things). Obviously, humans are not always honest. So, for the Release Burndown chart to be effective, the Team must be honest.
Work Remaining means also that we can potentially redefine ALL of the work. We can add stories, we can remove stories. We can break stories up (or break them down, if you prefer). We can re-story point stories. We can redefine stories or re-write them. So, then, the Release Burndown becomes as accurate as humanly possible as of that moment in time.
But why have a release burndown chart?
The second reason.
This information enables the Team to self-organize (around a common goal of hitting that date), self-manage (as if they were adults), and self-direct themselves to greater success. Or at least less failure.
Of course success and failure are not completely defined by hitting a date. But the date is the key element. The date is important because customers care so much about the date (or getting it earlier). And business (for a variety of reasons) cares about the date.
Side note: We discuss elsewhere at more length that happiness/fun and sustainable pace are also very important. And while we are increasing velocity, we must also insist that happiness/fun is going up, and hours are normal (I’ll say 40 hours per week, but we could debate the exact number of hours). More on this elsewhere.
So, anyone in the Team can use the Release Burndown chart. It is mainly for the Team.
Imagine a discussion after Sprint 3, heading toward a release in Sprint 6:
Person1: Wow! We are way over. By 20 story points.
Person2: Yes, we’re not going to make that date if we continue like this. We have to hit that date. [IRL, hitting the date is not always that important. But let’s imagine in this case that it really is.]
Person3: We still have some big stories. We need to break them down and see if we can move some of those story points to the next release. You know what Pareto says.
Person4: ScrumMaster, what can we do to increase Velocity?
Person5: If we could fix the [X impediment], I think the Velocity would go up 5 points.
Person6: We need to stop scope creep too. If anything new comes in, we have to tell the business side that something has to go out.
Person7: I’ll take some time in the next 2 days to help with the [X] problem.
This conversation all started with an observation about the Release Burndown chart. We are assuming that the Team can act like adults and, to some degree, control their own destiny. It may not happen, or may not be able to happen, every time. But it can happen often enough.
Notice also that there was no discussion of working overtime or on weekends.
I am about to do, in the next 2 months, three different inhouse courses. Well, actually more, since some clients will be doing more than one thing.
We do a variety of different things. The typical thing is that we need 10 people. And you save money.
But the key thing: It helps a lot.
The value for money is very high. Everyone is on the same page.
We have many options, but the most used ones are:
CSM course as an intro to agile-scrum for the whole Team (and people around the Team).
Agile Release Planning workshop. One key thing is that the build a product backlog, the real thing, and have a decent idea what will be in the first release.
Team Level-Up workshop. If you have a somewhat experience team that (mostly or at least partly( know agile-scrum, do this. Get them all on the same level. And we move them up at least one level.
Executive/Management workshop. We do this in a variety of ways. One is: (a) a 2 hour introductory workshop. This converys some basics and gives a real feel where they are coming from. Then we prioritize exactly what they need next. (b) a 4 hour workshop, of talk, discussions and exercises, that helps them rise in their understanding.
There is more information, click here. There is a listing on the page. And at the top a document with more details that you can download.
This is one in a series on Scrum Intro. The preceding post is here.
Now we come to the Burn Down charts.
You could start with either one, but let’s start with the Sprint Burndown chart.
We might first note that the Scrum Guide does not talk about a (Sprint) Burndown chart. There is a section in the Scrum Guide about “monitoring progress toward goals”, which mentions burn downs and burn ups.
I will recommend specifically the Sprint Burn Down chart.
What does it measure?
It gives our best guess, as of today, of the work remaining in the Sprint.
The way I recommend for beginning teams goes like this:
In the Sprint Planning Meeting, we create the tasks needed to complete the stories. I recommend putting hours to those tasks. I recommend the tasks be small (typically 2-4 hours each). And that a person (or persons) be assigned to each task. (This was all discussed earlier.)
Each day, the Implementers will get work done and learn. All of that information leads to revisions of the tasks. For example, some tasks can be replaced by other tasks. Tasks can be added. Tasks can be re-estimated. Tasks can be re-assigned to a different person, who gets to re-estimate the task.
Just before the Daily Scrum, the Implementers make all the changes and put them “in the pot” (by which, I probably normally mean, into the Scrum tool). And then someone (maybe the SM) can then calculate the net effect and therefore how much work is remaining now.
That enables setting the points shown above (as an example) and this the Sprint Burndown Chart.
The key thing is that this report is for the whole team.
The Team wins together or loses together.
So, the Team uses the Burn Down Chart to give them the information they need to self-organize, self-manage, and self-direct themselves to greater success (or less failure).
Some of the action by the Team is not discussed. It happens sub-consciously. Sometimes the SBD chart leads to a conversation, perhaps like the following:
Person 1: Yikes, we’re screwed.
Person2: Damn, well we have to do something. (And in that tone, from experience they know that means fix an impediment.)
Person3: I think [X] is the biggest thing to fix now.
Person4: I think the thing to do is [Y].
Person5: I’ll get started on that. Who can help me?
In this little conversation, you see the Team figuring out what to do.
The report is NOT primarily for others, but for the Team itself. They are the adults.
And we look for emergent leadership, people who rise in the occasion, and make it happen. firstname.lastname@example.org
The Sprint Burndown replies on the Team being as transparent, as honest, and as accurate as they can be about all the work remaining. And to everyone.
For example, if the Team decides that they will not complete a story, they might decide to stop working on it, and focus on stories that they still hope to complete. This is fine (or at least understandable that this will happen sometimes). First, they must be honest with all the people who care that that story is now “dead”. Then, they can take those related tasks out of the “work remaining”, and so, other things roughly as expected, that day we “burn down” more.
There is no point pretending that this day went well when it did not. Not point is pretending to make more progress than we really did. It does not help. It does not force us to make the changes we need to make it we “play pretend”. Equally, this can be challenging to managers, who too readily want to intervene if things do not go perfectly in one day. One day is not a problem. Even a “failed” (weak) Sprint is not a problem, so long as we eventually are successful.
Innovation work cannot be predicted with great accuracy and surprising things happen.
We recommend taking action and being willing to fail. We do not recommend forgoing all planning and all management; in fact, we recommend spending more (good and useful) time on those things. So that over time we end up being more successful. In large part by putting all our heads on the problem.
The next post in this series is [will be] here [TBD].
This is background information for a public survey. You can take our survey here.
The key purpose is to serve you better.
The needs of the larger group are diverse. Some want courses, some need workshops. Some people are looking as individuals, and some are looking for something for a group. Some are looking for public courses, and some for in-house courses.
One of our key concerns is to give you what you need where and when you need it. So, if we have 3 people from Group A and 3 people from Group B all want a course in NYC in Feb, then we create the course in February (if we can). That is, once we get 5+ people, we will create the course and confirm that with you.
Almost all of these are described more fully on this site, but here is a summary.
All of these can be done publicly or in-house.
All courses are 2 days unless otherwise indicated.
Best known course, best known certification. First thing to do for most people. Great for groups or teams.
If you want to get a team or teams started in agile-scrum, have them take this course together with the Agile Release Planning workshop.
This is the PO course, good also for ScrumMasters (who must improve the PO) and good for others on the business side who work with POs. This includes business stakeholders, business analysts, SMEs, and the like.
More people should be taking this course. A weak PO is typically one of the team’s biggest impediments. And the PO is not a weak person, but they are typically ill-trained and ill-informed about their role.
This is the new course defined by Scrum Alliance, on the Path to CSP. Aka – Advanced CSM.
This is an excellent way to develop your ScrumMasters and Coaches.
The way I will do it will assure you that your SMs are much more effective in helping the Team move all the important metrics: BV, velocity, happiness, quality, sustainable pace/reliability. It is fairly demanding (as input), but productive (people who can get better results). I require 3 days.
If you want a Team experience, we recommend the “Team Level-Up” workshop.
This is the new course defined by Scrum Alliance, on the Path to CSP. Aka – Advanced CSPO.
This is an excellent way to develop your ScrumMasters and Coaches.
Certified Scrum Developer.
This course is not offered much. But we will arrange one if you have sufficient interest.
We think it can be very valuable.
It is 5 days in total. Typically the first 2 days are the CSM course, and the next 3 days are advanced developer topics, typically using your stack.
Certified Agile Leadership.
This is a new course.
We certainly agree that your management and your leadership needs training. This course is good.
Another approach is our Executive/Manager workshops, which are customized to your situation. See below.
The style of these workshops varies a lot. Some more like courses and some very real, using real work.
These can be done publicly or in-house.
Agile Release Planning workshop
1 day. This workshop is done every time I do a CSM or CSPO. Or A-CSM.
We divide into “Teams” at tables. Each table identifies real work, that is an existing “project” or a set of work about to be started. It must real at the organization of the person who plays the PO role.
This is very important in changing the culture regarding planning. And very important for many of the basic skills to do agile planning. Important even just to get a good start doing agile-scrum. Hard to be successful at Scrum if your product backlog is crappy.
Team Level-Up workshop
A lot of teams need to level-up in one sense or another. I think every team, probably.
That is the teams need to (a) all get on the same page about agile-scrum so they can do it more successfully (aka level-set), and (b) they need to raise the level of their play.
That’s the purpose of this workshop. To take people or teams from where they are to the next level. And we expect this improvement to be measurable (higher BV, higher Velocity, higher quality, faster TTM, higher happiness, more sustainable pace, more reliability, etc.).
People may come with all or part of their team. Or we can take people and add them to a table, which acts as a team for the work
This is a 3 day workshop. Two days are exercises and discussions.
The third day is the Agile Release Planning workshop. If people have done it before, we expect them to raise the level of their play and raise the level of play of the team they are with.
Scaling is a problem and important. And expensive.
Rather than talk about lots of patterns that you might use (using Method A or B or C), we like to get into your real situation, and help make you better now.
We want to take about 7 people that represent the people you are doing scaling with. Mostly managers, but I strongly recommend also some people inside a team or two.
Then we want to identify the current state (and its issues) and the future state (and its benefits). And then talk about how to move from current to future. Implementation is hard, and usually that is what restricts what we can do in the next 6 months.
We do talk about patterns, but the workshop is very practical. What is the problem? How do we solve it? (We do care we have the most important problem.) End result: Your group of 7 people is agreed on a game plan for change.
We could have two different groups in the room at the same time. This is typically very educational for all parties.
This can be done for 1 day or 2 days.
User Story / Story Splitting workshop
We help you team write user stories. And more importantly, we help they think about and practice breaking up the user stories. Often they find this hard or “impossible”.
This is very important. Large user stories in the sprint are a key reason for lower velocity, “failing” sprints and other problems.
We can have multiple teams in the room.
We usually can do this in half a day.
Impediments List workshop
Many teams do not have an Impediment List. Or, if they have one, it is not very good.
The standard version of this workshop has whole teams attend. Multiple teams is fine, even better. We can also take individuals and add them to tables, which act as a team during the workshop.
We help the team create a better Impediment List. We help them learn how to prioritize it (better). And we have them practice taking action on impediments, especially in making proposals that managers can approve.
Obviously, if you have 3 similar teams in your company, you can see the synergies in doing this together.
We can do the workshop for half a day or a whole day.
Agile/Scrum For Executives and Managers
This workshop is highly adaptive to your needs.
We can take 1 hour or 8 hours. They need lots of training, but often they will not take much extended time to go into it.
Our preference is to typically take 1-2 hours, and give an intro and get to know your people personally. This has some interactive elements but often is mostly basic education. All the people and politics stuff becomes much more understandable to us. Then we discuss with you, and plan a second session, typically 2-4 hours more. This tends to be more interactive. The goal is to move them up the agile scale as much as possible. To help them become more effective in an agile environment (ie, we expect some of their behaviors to change). To help them feel comfortable (at least lower resistance from some). To help them become more effective advocates of agile (at least for many of them).
We can also do a 1 day “Intro to Agile-Scrum”. This can be helpful also. The expected outcomes are more on the “introduced and educated some” area.
We have done this many times, and each time it is notably different. Let’s talk about your specific needs.
Please tell us if you have questions or want more information. Info@LeanAgileTraining.com is a start.
Specifically, you have to demonstrate in the course that you can explain things and DO the things indicated in the Learning Objectives. This is a hard test.
In my case, I will want to know that you can make change happen. And that you have learned some of the skill sets (aka Learning Objectives) that will make you better and better at making real change happen, in the context of Scrum.
You can take the course first and get the experience later. But no A-CSM without the experience. You could have gotten the experience before you took the CSM, in theory.
You can get the experience in any combination of before or after the course.
This is one in a series on Scrum Intro. The preceding post is here.
This artifact is different than many suppose.
It is the list of stories and the list of tasks for those stories, that the Team thinks they can get done in a Sprint. (In my mind, the normal sprint should be 2 weeks in most cases, so, in 2 weeks.)
The Sprint Backlog is created in the Sprint Planning Meeting.
The Stories in the Sprint (in the Sprint Backlog) come from the top of the Product Backlog. Again, the Team gets to decide how many stories to pull into the Sprint.
The Scrum Guide describes it a bit differently. The Plan that the Scrum Guide mentions does not have to be a list of tasks for each story.
Having small tasks for each story is a very good discipline that most teams need. But, if they get more successful and want to experiment with that a bit, then fine.
As we said before, the tasks must be small. We want to see (or maybe not see) that each person is making some progress each day. So, the small tasks (or very small stories) make that progress more clear.
This clarity enables the Team to self-organize better. For example, key problems can be identified and attacked.
The Sprint Backlog becomes the Scrum Board, which is a kind of visual management. More specifically, the Scrum Board is a kind of kannan board. So, kannan, or a form of kannan, is baked into every basic Scrum implementation.
The Scrum Board is usually composed of several columns and rows. The columns are often titled: Backlog, In-Process, To-be-tested, and Done. And there is one row for each story. It is expected that only 1 story is “in process” at a time. Well, that level of minimization of WIP (work-in=process) is a bit tight for beginners. So, normally a Team has two stories in process at any time. But in any case, the situation is usually pretty clear from the Scrum Board, or at least after a brief conversation about the Scrum Board.
Some people complain that the Sprint Backlog is micro-managing. And, indeed, often the work is more broken down (for the 2 weeks) than you often find in a waterfall project. But, the Team is not being micro-managed by someone else (or at least that is not the intent).
The Team creates the Sprint Backlog. The Team volunteers for the Stories and the Tasks. The Team is NOT supposed to ver-promise, but only sign up for the work that that data says they have a history of doing. Unless there is a very good reason to believe the Team now can do more. Two examples: Now Person X is back from the vacation that happened in the prior Sprint. Or the SM has fixed impediment Y, and not the velocity should be higher.
Little things are big. And, the bad news does not get better with age.
And so, by seeing the small problems sooner, the Team is able to take corrective action sooner. And the impact is greater.
Is the Sprint Backlog perfect at the moment we complete the Sprint Planning Meeting? NO!
So, we expect the Sprint Backlog to be revised and improved as the Team does the work and gets smarter. So, at least once each day, anyone on the Team can revise the Sprint Backlog. In general, sooner or later a team member should explain why the Sprint Backlog was changed, if only briefly.
Note: This is one in a continuing series of posts re Scrum Intro. The preceding post is here.
Now we turn to the artifacts in Scrum.
First we have to be clear: There can be many many artifacts for a team depending on the work and how you define artifact. So, the main artifacts we will discuss here are what we consider the core Scrum artifacts.
My list is this:
The Product Backlog
The Sprint Backlog
The Scrum Board
The Sprint Burndown Chart
The Release Burndown Chart
The Definition of Done
The Impediment List
My list is not what you will find in the Scrum Guide. So, when they are not mentioned in the Scrum Guide, I will explain a bit more.
Do we have to use all these artifacts every time? Well, of course not. Use common sense. If you are quite confident that an artifact won’t help you in your specific situation, by all means do not fool with it. Just, be careful. Common sense is not very common. That’s a Ken Schwaber saying, I believe. What I think it means is we are so easily captives of the old ideas and so we do not see the truth of the current situation well enough. Often we do not make the right decision, so be careful.
Should I have other artifacts? Do you recommend other artifacts? I often get these questions. The answer is probably “yes” in both cases. Again, we are only discussing the most basic Scrum artifacts.
Let’s mention one more artifact (or someone could call it an artifact). That is, the Scrum tool.
There are many many Scrum tools out there — none are identical. They do many things and they vary a lot, but typically they hold the Product Backlog and the Sprint Backlog. Often they do more such as generate the burndown charts, show a Scrum Board, etc.
Well known Scrum tools include using Excel, Rally (recently renamed within CA), Version One, Jira, Pivotal Tracker and many, many more. Some of the Scrum tools (other than the ones above) used to be lame a few years ago; now most of them are pretty decent. You should probably have a Scrum tool, even if it is only an Excel sheet.
Our goal in this paper does not include addressing the Scrum tool as one of the artifacts. OK — now let’s discuss each artifact I mentioned above.
This is one in a series on Scrum Intro. The preceding post is here.
The Product Backlog is usually the first mentioned of the artifacts. In some sense, Scrum starts with the Product Backlog, or at least the first Sprint cannot start without a Product Backlog. The Product Backlog is a list of all the work for the team. We also think of the Product Backlog as the list of all the new features for the current product.
One name for the items in a Product Backlog is PBI (Product Backlog Items). We also speak of those items as User Stories, especially if they are in the User Story format.
The User Story format is:
As a <end user role>
I can <do something>
So that <explain purpose or next step or because>.
Who can contribute
It is important that the Product Backlog include all the work of the team. More on this later.
Anyone can contribute to the Product Backlog (the PBL). This is important and often mis-understood. Any team member can propose a PBI. Any Business Stakeholder can propose a PBI. A customer can propose a PBI. The PO can judge an item out of scope. The PO can improve the quality of an item proposed for the PBL. The PO can rewrite a PBI.
The PBL is prioritized. The final prioritizer is the PO. By this we mean that anyone can suggest things to be considered in the prioritization or suggest new data that would affect the prioritization. In general, we first say that the prioritization is mainly based on Business Value or the value to the end customers.
Later we say that prioritization should mainly be by POI (Business Value divided by investment — with investment being mainly cost or effort). In truth, there are other factors as well (dependencies is a key factor).
The Product Backlog should go out a reasonable amount. Jeff Sutherland has said a typical length is one year for a typical product. Surely this could be less for some products and more for other products. In my experience, many PBLs do not go out far enough.
This is actually a serious problem, because it means that the PO is choosing from too few items “what is the most important PBI to work on next.” That means that the team is typically not working on the most important thing it could be working on.
The 80-20 Rule
In general, for a given product, the PBL should help the PO do the 80-20 rule or something close to it. That is, the Team does 20 percent of the work and delivers 80 percent of the Business Value. This is hard to do (for many reasons), but focusing on this issue is very very useful. For example, if the team did 20 percent of the work and got 50 percent of the Business Value, that would be a serious and very useful improvement.
Kinds of Work
The PBL should include all the different kinds of work the team must do. The PBL should include any legacy bugs, meaning bugs or defects that existed before the team started this working on the product. The PBL typically includes technical debt (sometimes expressed as technical stories). So, the PBIs include stories to fix the technical debt.
If we are automating QA tests, then the PBL probably needs to include PBIs to automate the existing manual tests or needs PBIs for the work to set up or improve the automated testing.
Sometimes we have a separate list of “small enhancements.” Often these enhancements are small changes to the existing set of features. When we describe the vision of the next release of the product, it does not include small enhancements to the existing features. Hence, these small enhancements are often work outside the vision of the next release — except that someone feels we must do some of them. There can be other categories.
We do not have separate Product Backlogs. Each team only has one Product Backlog. Hence, “everything” (all the different types of PBIs) must be prioritized together in one Product Backlog. Not always an easy job.
The Product Backlog must be refined or groomed over time. New items are identified later, and may be identified soon as part of the current release or maybe a later release or maybe never will be built.
Product Backlog Refinement or Product Backlog Grooming includes many things. Among them are identifying new stories, breaking up larger stories (stories too big to go into a Sprint well), putting Story Points on stories, adding or revising the Business Value points on stories, adding details to stories (as much as the team needs), reorganizing the order of the stories, etc., etc.
We have a whole book to describe Product Backlog Refinement. See our book on Agile Release Planning.