This is the third part of the Scrum Deconstruction. You can find part 1 here, part 2 here and part 3 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org’s PSM I exam that I took back in October last year. I have made updates based on the newest version of the Scrum Guide, November 2017.
Here I share in the hope that someone finds it useful.
Sections in Blue will be taken from the Scrum Guide. I’m not going to do a cut and paste, but re-type out what is present. Therefore there may be mistakes.
Sections in Black will be me rephrasing or my interpretations of the paragraph. This I would like to think of as the positive aspects of Scrum.
Sections in Red will be the negative aspects that I see, or have been told, read or anything else negative. Sometimes these will sound silly (and probably are) as it I find it difficult to find negative aspects, this is where I ask for help. If you have more constructive negative feedback about a paragraph, please let me know in the comments.
Side Notes are in green.
Now, lets get on with the deconstruction.
Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the Product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The Product Backlog is just a list of items. That list doesn’t have to be user stories. It also doesn’t have to be in Jira.
It can be in excel, cards, a word documents, hand written on paper. It isn’t specified. The practices of how the Backlog is kept is independent of Scrum.
It is the single source of requirements. That means that if someone wants to do something, it must go on the Product Backlog, and since the Product Owner is in charge of the Backlog, it must go on with their blessing.
That means that even if the CEO wants something done, they don’t go directly to a developer, they go to the Product Owner. This means that the Product Owner position is one of respect. No someone who’s a managers lacky.
The list also needs to be ordered so that when the list is looked at during planning, or if the development team finishes the Sprint Backlog early, it is easily known what is the most valuable work is.
What if everything is of equal value. I’ve had that before!
Then nothing is of value. This is an antipattern. The Product Owner wants everything, so everything is of equal value. This is then used to rush developers. Which leads to shoddy work as the developers try to complete everything in the Sprint. This then leads to Technical Debt and problems in the future.
There is always something of high importance\value. This needs to go first. Then the next valuable piece of work and so forth.
A Product Backlog is never complete. The earliest development of it lays out the initial known and best understood requirements. The Product Backlog evolves as the Product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a Product exists, its Product Backlog also exists.
When you first start, you do not need to work out everything initially. It will all change anyway as new things are learned. You cannot know everything up front. What you know initially, start working on. Work out the rest later. The later you can delay decisions, the more time you will give it to change. So that when it get time to do the work, hopefully – not always – the changes will be minimal.
The Cone of Uncertainty
As you get closer to the finish of the work, you start to get an idea of what the end will look like. At the beginning, you don’t know what problems you will face, therefore in order to better predict the outcome, you need to work in small goals.
You reduce the unknown to a short interval. Deliver to that interval and at least that small sections is known. Yes it can change, but you are delivering value sooner.
This is why the Product Backlog should be dynamic.
Even though the “Project” is complete, changes, bugs, new features, unfinished work still exists. These are stored in the Product Backlog as well so that they can be worked on at a later date, when there is more time or budget.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the Product in future releases. Product Backlog items have the attribute of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
The Product Backlog contains everything needed for the Product. This includes DB, servers and other non-functional as well as functional requirements.
Each item should have a:
- Description : These tend to be in the form of stories
As a …..
I want ….
So that ….Yay!
but they do not have to be. They can be a header, a paragraph, a video, drawing. The important thing is that they have context to how the item fits in, and convey enough information to know what the work is. - Order : Generally what is needed and most valuable at the top, least valuable at the bottom. Make it easy for the team to know what to work on without them having to ask. Also think, if you were to run out of money in the next Sprint – what would you want most!
Just don’t like I mentioned above ask for everything. - Estimate : So you have a guide as to how long or how much effort the item will take.
Note : Scrum does not specify the method of estimation. You can use Story Points, T-Shirt sizes, animal sizes, or dare I say it, time.
There are reasons why you should not use time. I won’t go through them here. - Value : This could be in the form of ROI (Return on Investment, time saved etc. This helps give context as to why the work is being done.
Some companies include ROI, even in non-Scrum projects. The problem is that at the end, the ROI is never verified. You never know if the value is realized or not.
This is not good. - Test Descriptions : These help the Developer know that they have built the right thing. Again there are many forms, but the more detail included, the better an understanding the Developer has. Tools like Cucumber, Fitnesse, Concordion can help automate verification by allowing tests to be described in English rather than code.
As the Product is used and gains value, and the market place provides feedback, the Product Backlog becomes a large and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Change in business requirements, market conditions, or technology may cause changes in the Product Backlog.
The only way to know if the Product will be useful is when it is used. Real hands on. Not labs, not trials, but real people using the product in anger.
You will then know its short falls. The fixes, changes, extra functionality then gets added to the Backlog.
A ‘Product’ is a long lived thing unlike a ‘Project’. Requirements evolve, there is no end until the Product dies for whatever reason.
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to decrease the upcoming work on the Product. A Product Backlog attribute that groups items may be employed.
One Product Backlog, one source of value. Everyone works togehter to get the most value sooner.
Product Backlog refinement is the act of adding detail. estimates and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of the Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.
However, Product Backlog items are updated at any time by the Product Owner or at the Product Owners discretion.
Product Backlog refinement is where you go through items in more detail. Break down the items to smaller pieces of work. Get acceptance criteria added. Work out in detail what needs to be done for each item. Not too much detail, but just enough. How much is enough? You have to work that out by trial an error. There are no easy rules.
Refinement should not take more than 10% of the time, but you can take less.
More meetings, when do you get the work done?
Refinement is done anyway, even in waterfall projects. Its more hectic and ad-hoc when you do not specify a time.
This is a requirements gathering process. Rather than spend a whole heap of time up front, you are doing this during the development.
For Developers, this may seem to be an issue. BAs do the requirements gathering traditionally. Put them together and hand them over to the developer for coding.
In Scrum, there are no BA roles. You, the Developer are the BA, the Tester and the Developer. Look at it as an opportunity to learn. Not a “Not my job” situation.
Higher order Product Backlog items are usually clearer and more detailed than lower order ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can be reasonably “Done” within the Sprint time-box. Product Backlog items can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of Transparency through the above described refining activities.
The closer you are going to work on an item, it needs to have more detail. This makes sense. Why would you add more detail to an item you won’t look at for some time, while neglecting upcoming work?
Get the items to a point you can start and finish the work in a Sprint. Don’t do half the work now and the other half next Sprint. Treat the work as if this Sprint is you last. Any subsequent Sprints (even planned) is a bonus. At least during the planning.
This is a definition of “Done” which we will get to later, but should there be a definition of “Ready”?
The Development Team is responsible for all estimates. The Product Owner may influence the Development team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.
Have you ever been in the situation where a manager gives you a piece of work, expects it to be done in a few days, instead it took you a few months (I’m not talking Scrum here – but traditional development)?
This statement is to give Developers the ability to say it will take a few months. Not a few days. They should know – they are doing the work.
Monitoring Progress Towards Goals
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with the work remaining at previous Sprint Reviews to assess progress toward completing the projected work by the desired time for the goal. This information is made transparent to all stakeholders.
This is giving the description Burndown chart, without explicitly saying Burndown Chart because it limits thinking of other ways to describe the data. Some of which are mentioned later in the guide.
This is basically the sum of all estimated work remaining compared to the previous sum. Compared to all previous Sprints you get a trend over time on how work progresses. This can be used as a guide to determine when the work will be completed.
Various projective practices upon trending have been used to forecast progress, like Burndown, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making .
Various examples are given to represent the data. What this data shows is a rate over time think of this rate as showing your speed on an odometer. If you are on a freeway, your speed is 100kph. On a suburban road it can drop to 50kph, a school zone and it’s 40kph. This is the known limits, and estimates can be derived data, but what happens if there is an accident on the road, road works, traffic, a special event? Your rate changes, your estimated time of arrival (delivery) changes. These need to be taken into account – but after they occur. A good GPS system will do this for your journey. You have to do the same thing for your journey in doing he work.
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next increment and the work needed to deliver that functionality into a “Done” increment.
A Sprint Backlog is:
- Selected items
- A plan for delivering of the increment and the Goal.
It is a forecast, not a contract.
I have heard Scrum Masters mention Commitment to the work. This language I think is dangerous. It can be taken as ‘hell or high water, this amount of work will be done’.
this can lead to late nights, long hours, working weekends to complete an illconcieved Sprint Backlog. this is not what we want. A Sprint is a timebox – not a deadline and we are trying to measure the ‘rate’ of work at a reasonable pace.
NOT ‘get all this stuff done before the Sprint Deadline’
We can get booked for speeding on the road. Scrum Masters should be booked for “speeding” their teams (driving them too hard) otherwise just like an engine, they will burn out.
The Sprint Backlog makes visible a,, the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes one high priority process improvement identified in the previous Retrospective meeting.
This last statement of including at least one improvement is key to getting better. Unfortunately many teams do not do this, or do not see it as a priority. Thus it gets dropped off.
High Performance teams already do this as mentioned by Ken and Jeff when this version of the Scrum Guide was released.
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the daily Scrum.
The Development Team modifies the Sprint Backlog throughput the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
Unlike Waterfall, with Scrum you do not work out everything up front. You are not supposed to. How many times have you worked on something only to find a detail that you forgot, didn’t know about, had a problem you could not solve and had to figure out a work around? Scrum takes these things as fact. Shit happens. So don’t plan too far ahead because it is all going to change anyway. Just plan enough to get by for now and a little ahead in the future. We learn as we go.
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change the Sprint Backlog during the Sprint. The Sprint Backlog is highly visible, real-time picture of the work that the Development Teamplans to accomplish during the Sprint, and it belongs solely to the Development Team.
As the Development Team works, things missed get added to the Sprint Backlog, or something drops odd in the Sprint Backlog back into the Product Backlog.
One thing about Agile is that we try to minimize the work done. If something is no longer needed – drop it. Don’t do it anymore. Makes sense right? It is best to find out as early as possible if something is needed so that you do not waste time even just thinking about the redundant item. It’s amazing how much work is done that is not required.
The Sprint Backlog should be visible to all. This is why you can see Scrum boards. It’s a visible way to see the work.
By making it visible – everyone can see the progress. Nothing is hidden.
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks the total work remaining t least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
Much like the Product Backlog, remaining work can be tracked, checked and determination of completing the work be done. This should be done at least daily, during the Daily Scrum. This is through moving the cards on a Scrum wall – that is if you use the Scrum wall. What I have seen is that what is missed is checking if the Sprint Goal is likely to be accomplished.
This statement again disproves the “What I did yesterday, what I will do today, any blockers” statement. These should be discussed and answered during the daily scrum, but they are not the only things that should be done during the Daily Scrum.
Again, this emphasises that this is a responsibility of the Development Team. The Development Team are masters of their domain.
Increment
The Increment is the sim of ll the Product Backlog items completed during the Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new increment must be “Done” which means it must be in a usable condition and meet the Scrum Team’s definition of “Done”. An Increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The Increment is a step toward a vision or goal. The Increment must be in usable condition regardless of whether the Product Owner decides to release it.
Basically an increment is all the work done to date that has been fully completed and is in a state that the Product Owner will find usable to some degree.
By Definition of “Done” which is discussed later, it mast be code reviewed, have error handling, follow standards, be tested and be at a point ready for release. By doing this up front – even for work that is not i a fully complete state, i.e. still has many months left to bring it to full spec, you:
- Get feedback sooner. If left till fully ready after months, without checking you run the risk of not making what the client needs or wants.
- If budget runs out, the client still has something usable. Even after the first 2 weeks.
- It forces you to think in smaller chunks of value rather than just going for the whole thing.
The Product Owner is the best person to know when to release as they know when the product will give the most value to users and stakeholders.
By having the increment in a “Done state, there is no reliance on “fixing” bugs or any other trepidation before release as they should have been looked at beforehand.
Artifact Transparency
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions are flawed, value may diminish and risk may increase.
Have you ever worked on a project where you know that the whole thing will be a mess, you tell the Project Manager that it will last less than a day before it completely fails, but they release it anyway because the Project Manager told Management everything was O.K.
Ever been in a project where everything was green up until a week before release?
These problems occur because information is hidden. It usually ends badly and it occurs so frequently that it is considered normal.
Scrum relies on everyone knowing everything and by everything, I mean the correct information. No lying or bending the truth. That way good decisions can be made.
But for this to happen, there must be an environment where it can happen without repercussions.
i.e. There must be TRUST!
The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artefacts are completely transparent. There are practices for coping with incomplete transparency. The Scrum Master must help everyone apply the most appropriate practices in the absence of compete Transparency.
A Scrum Master can detect incomplete transparency by inspecting the artefacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.
It is the Scrum Mqsters job to try to teach the Product Owner and the Development Team to be transparent.
Some technologies are:
- Kanban Board/Scrum Board
To visualize the work. - Gather Metrics
– Length of time of a ticket/item not worked on or - Retrospective Techniques
Sometimes by just listening to the Team the Scrum Master can get a sense that something is wrong.
For example, mumbles about work, management, hiding stuff from the Product Owner.
The Scrum Master must help the team expose these to they can be addressed.
The Scrum Master’s job is to work with the Scrum Team and the organisation to increase the Transparency of artefacts. The work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.
The job of the Scrum Master is not an easy one. If done right.
There is so much resistance to true agile. It is much easier to follow the “Process” and be ignorant of the reasons as agile shows problems. It is far easier to hide and ignore those problems.
The road to transparency if long and arduous. It is a journey without end, which is fine as the journey is what is important – not the destination.
Definition of Done
When a Product Backlog item or an increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the Product Increment.
Have you ever thought something was done only to find out that there was a requirement . or a portion of the work that needed to be done to complete the piece?
Have you ever built something only to find out that it wasn’t what the customer or end user had in mind and have to start all over again?
This is what the “Definition of Done” is for. To make sure every one is on the same page, and has a shared understanding of hwat needs to be done to complete the work.
Because everyone has their own understanding of a “requirement”, the customers understanding needs to be “extracted” from the customers brain and “implanted” into the development team. My favorite method of doing this is through examples.
Stealing from Gojko Adzic’s book “Specification By Example“…
Lets say that the customer has asked for a “10 point star”. A simple requirement.
So… you produce the followiing…
Is this correct? Well, that is up to the Customer. In this case, the customer says “No, go back and try again!”
Racking your brain, you have no idea what the customer is asking for. So you ask them to sketch it out.
Huh? Thats a 5 point star!
No, says the customer, its 10 points!
Ah! you now say. I know what you are thinking!
A simple example of hat is expected can enlighten all on what is required.
This will then reduce re-work and mistakes on misunderstandings.
Other things can include having a list of what needs to be done. Such as…
- Tested with Automated Tests
- Following coding standards
- Documentation complete
- Meets acceptance criteria
- Code reviewed
- No known defects
- User acceptance tested
even - Migrated to production
The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver increments of potentially releasable functionality that adhere to the Scrim Team’s current definition of “Done”.
This means that you select items from the backlog that produce some functionality that is useful.
Not half of a piece of work one Sprint and the other half the next Sprint.
“There is no next Sprint!”
The next Sprint should be considered a bonus that is not guaranteed.
Therefore select items accordingly. Reduce scope if need be.
Development Teams deliver an Increment of product functionality every Sprint. This Increment is usable, so a Product Owner may choose to immediately release it. If the definition of “Done” for an Increment is part of the conventions, standards or guidelines of the development organisation, all Scrum Teams must follow it at a minimum.
If the Product Owner chooses to “release” the “functioning” product, this means that value is returned “sooner” than if the project was complete.
It also means that any learning from the product in production can be done sooner, thus determining if the work was valuable or not. It is not, stop working on that feature and try something else. If it does – continue working on the feature.
If the Product is “good enough” then the Product Owner may choose to not continue with the rest of the project.
This is known as “chopping off the tail”. There is no use continuing as all required functionality is already delivered.
This is another reason – from a customers perspective to get things in use by the users ASAP.
Also, if the company has existing standards, incorporate them inthe “Definition of Done”, but review them regularly. You may find some no longer relevant or appropriate. A good place to look at this is a Retrospective, but that should not be the only place. You should do it during the Daily Scrum, Planning sessions etc.
Inspect and Adapt!
If “Done” for an Increment is not a convention of the development organisation, the Development Team of the SCrum Team must determine a definition of “Done” appropriate for the Product. If there are multiple Scrum Teams working on the system or Product release, the Development Teams on all Scrum Teams must mutually define a “Definition of Done”
IF there are no company wide or team wide conversions for “Done’, make your own. Call out what you want to make it happen to make sure you make a quality product.
Make sure that all Scrum Teams that work on the same Product share the same quality values and “Definition of Done”.
If you do not do this, you will find portions of the Product in non-working order or of dubious quality.
Its just common sense.
Get the Teams to decide their “Definition of Done”, don’t dictate it to them (unless it is an existing definition). If they define their own “Definition of Done”, they have buy in. They may get more engaged.
The Team may care more about meeting the “Definition Of Done”.
Each Increment is additive to all prior increments and thoroughly tested, ensuring that all Increments work together.
Each Sprints output builds on previous Sprints. This means that you need to make sure that past components developed still work. This means regression testing.
Agile won’t work easily with manual procedures. There just isn’t enough time. Therefore you need to automate.
- Automated regression testing
- Automated deployment
Basically, reduce the time ti takes to do stuff.
But don’t do it up front. Do it along the journey. That way you only automate what you need to.
Keep doing the improvement as you go along. That is the whole point.
As Scrim Teams mature, it is expected that their definition of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is standard for any work done on it.
The goal of Scrum is continuous improvement – not to keep the same pace, the same steady run. As you get better and stretch your abilities, your definition of Done should also evolve.
This may include:
- Severity goals
- Reviewed by legal
- Penetration testing
- Performance testing
- Continuous testing/Integration/Delivery
and any other criteria that you may wish to include.
You can’t add this sort of thing until you get better, faster and more ‘agile’. Yes, I mean agile in the dictionary meaning – not as in the Process or Methodology.
End Note
Scrum is free and offered in this Guide. Scrum’s roles, events, artefacts, and rules are immutable and although implementing only parts of Scrum is possible, the result s not Scrum. Scrum consists only in its entirety and functions as well as a container for other techniques, methodologies, and practices.
Ok, for those that complain that you need certifications to so Scrum or to be a Scrum Master here is the proof that you do not need any of those things.
Scrum is free!
I remember about 20 years ago, you ha to pay to use the Rational Process to develop software. This is not the case with Scrum.
Also, those places that do “Scrum” but do not do Retrospectives or Daily Scrums/Stand ups – you are NOT doing Scrum.
Saying that, you an still not be doing Scrum if you follow the “Process” to the letter but ignore the underlying reasons for the process. Which basically is to get better. You get better by finding and fixing problems. Not by blindly following the process. The process is there to guide improvement actively over a Sprint, not organically as required whenever or every now and then through workshops.
Remember the beginning. Scrum is a framework on which to build improvement. Techniques such as Scrum Boards, User Stories, Scrum Poker, Story Points are not part of Scrum but still can be used. This is known as Scrum-and as opposed to Scrum-but where parts of Scrum are used.
Finally!
For those that are interested, as I mentioned in the first post, I have hand written the Scrum Guide and my decomposition. You can find a copy here. Fair warning, its a large 80+MB pdf file.
I started this a year ago when I decided to do this as part of my study for the PSM I Certification. Hopefully you have found this useful. Please let me know in the comments.