Scrum Guide Decomposition Part 3

Well, that was a long hiatus that I didn’t expect. I usually write while my better half is at work, but she has been at home injured so I’ve been spending quality time with her until she is better.

This is the third part of the Scrum Deconstruction.  You can find part 1 here and part 2 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.


Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
Note : Its says “minimize the meetings not defined in Scrum, not exclude them”

All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

If you decide 2 week sprints. Stick to it, if you decide 1 week, stick to it. Some teams start to try different lengths when they first start. They may try 2 weeks, 1 week or 3 weeks, but once a decision is made on the sprint length, stick to it. Don’t chop and change sprint to sprint when it is convenient. Make it like clockwork.

I don’t work in 2 or 3 week blocks, I just do the work.
That’s ok, you don’t have to work in sprints – but that then isn’t Scrum. See Kanban.

The Sprint gives a regular time everyone knows and can thus work to. It will also force you to create something in the end. The pressure (not too much, not too little) can help foster innovation as you have to produce something.

The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

By fixing the maximum time, you prevent events from taking too long. It prevents them from going forever. It also helps focus the event to get the result. The sprint is different. It generally does not end sooner. For example, when the sprint backlog runs out prematurely. In this instance, you just pick up more work from the Backlog.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something.

Look at each event as an opportunity to look back at what you have done and try to improve. Don’t just leave it for the retrospective.

These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

Also too, if you treat the event as a “tick in the box” event, you reduce its effectiveness.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product increment is created.

You should create something useful. Not documentation, not a plan, not an environment. It can be small. Only do one specific thing in a narrow field, but make sure that it is usable.

Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous sprint.

There is no “a few days/hours of planning” before the next sprint. Everything is incorporated in the sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

When, with all that stuff do you actually work?

A Sprint does nothing outside a normal project. It just does it in smaller blocks. Rather than all planning up front, like in Waterfall.

During the Sprint:

  • No changes are made that would endanger the Sprint Goal;
  • Quality goals do not decrease; and,
    This is important. When companies start Scrum initially, they push to get things done quicker. When this happens, the first thing to go is quality.
    But saying that, what is quality? You need to seriously look at what quality is and strip out the waste.
    Eg. Documentation, having a 100 page spec that no-one reads or can understand is not quality
    Having a concise document or diagram that everyone understands is.
    Also have coding standards, etc well documented and be able to be verified. Nothing based on individual opinions.
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
    Scope is not fixed. It varies as you learn more.

Each Sprint may be considered a project with no more than one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

How many projects just produce documentation or specifications? Each Sprint is a self contained project. Just smaller. And no, its not quite like a small Waterfall project, its so much more.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress towards a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling A Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the Stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if the market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But due to the short duration of Sprints, cancellation rarely makes sense.

Sprints are cancelled if a radical change in Goal is required. Something seriously must be wrong if you cannot wait 2 weeks, or a month before you chop and change.

When a Sprint is cancelled, any completed and “Done” product backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog items are re-estimated and put back on the product backlog. The work done on them deprecates quickly and must be frequently re-estimated.

Knowledge fades fast. If you are working on something and have to put it aside for a period of time, then come back to it, you need to get re-acquainted with the work. That takes time. The partially done work needs re-estimation because you need to estimate how much “remaining” work needs to be done. Estimation is a tool to help you determine capacity, it is not a goal in itself to “complete” a certain amount of work, but a tool to help you plan how much work you can be done within a Sprint.

Sprint Cancellations consume resources, since everyone has to re-group in another Sprint Planning to start another Sprint. Sprint Cancellations are often traumatic to the Scrum Team, and are very uncommon. They are a waste.

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum team.

Sprint Planning is time boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Eight Hours! Seriously. When do you get the work done!

Eight hours is only 1 day. That is 1/20th the time. A small price to pay to know what you are doing during the Sprint.

Sprint Planning answers the following:

  • What can be delivered in the increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the increment be achieved?

Topic One: What can be done this Sprint?

The development team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum team collaborates on understanding the work of the Sprint.

The objective of the Sprint is some functionality that can be used. Something small, but useful. It may be incomplete, but still useful. The Product Owner needs to get what is in their head into the Developers Head with regards to the objective – not the solution. But – the whole Scrum team needs to work to understand.

This is different to standard practice where a Spec is handed over and everyone works to it. Specs can be interpreted differently. The idea here is to remove the different interpretations, remove the ambiguity to the goal.

The input to this meeting is the Product Backlog, the latest product increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.

The number of items selected from the Product Backlog for the Sprint is solely up to the Development team. Only the Development Team can asses what it can accomplish over the upcoming Sprint.

The Development team has the right to refuse work. This is hard because most people want to please. The environment must also be safe enough for the Development Team to reject work. Therefore the Scrum Master should back the team and the Product Owner should respect the decision.

Contrary to current management where you get what you have been given.

Will never work, Management pushes.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum team crafts the Sprint Goal.

The whole team crafts the oal

  • Dev Team
  • Scrum Master
  • Product Owner

The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the increment.

The Sprint Goal is functionality to be delivered.
Eg.

  • Blogging product
    • Be able to post a blog
  • Purchase Order System
    • Be able to raise a purchase order
  • Ambiguous
    • Make the CEO happy

Topic Two: How will the Chosen Work get Done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into the “Done” product increment during the Sprint.

The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

The second half of the Sprint Planning is determining the Plan to produce a done increment. Remember the backlog items should not be a “solution”. They are required functionality.

The Development Team usually starts by designing the System and the work needed to convert the Product Backlog into a Product Increment.  Work may be of varying size, or estimated effort.

Note. Estimation of “effort” not time!

However, enough work is planned during the Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.

Note. No mention of stories. Stories are not part of Scrum. Scrum does not specify the method used to format items.
Work is broken down from large to small. One day or less is not just development, but everything including testing where possible.

The Development Team self organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

Self organizes, thus no one, including the Scrum Master assigns tasks to individuals. The Scrum Master must encourage the team to Self Organize.

Without someone directing, how will people know what to do? They will end up doing nothing!

That is why you need motivated people.

The Product Owner can help to clarify the Selected Product Backlog items and make trade-offs.

This is through negotiation. There is a certain amount of capacity that a team can handle. Over extend and something suffers. The goal is that the only thing that suffers is scope.

If the Development Team determines it has too much or too little work, it may re-negotiate the selected product backlog items with the Product Owner.

Too little – add more

Too much – remove some

The Development Team may also invite other people to attend in order to provide technical or domain advice.

But these people do not participate.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a Self organized team to accomplish the Sprint Goal and create the anticipated increment.

This is a feedback mechanism to let the Product Owner know the Development Team understands the requirements. It also forces the Development Team to put a strategy together on how to do the work.

Sprint Goal

The Sprint Goal give the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected product backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

The Goal could be the problem to be solved. It is basically something larger and more meaningful than just “the work”.
It also needs to be something that guides the developers decisions.

Sprint Goals should be S.M.A.R.T. Goals.

Specific
Measurable
Attainable
Relevant
Time Bound

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different then the Development Team expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint.

Daily Scrum

The Daily Scrum is a 15 minute time boxes event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

15 minute max – regardless of team size or Sprint size.
It is also not a status report.

The Daily Scrum is held at the same time and place every day to reduce complexity 
This is a test question!
During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediments that prevents me or the Development Team from meeting the Sprint Goal?

Its stupid to have everyone standing around answering these questions – just do the work!

These questions do not specifically have to be answered on after another. The idea is that the team huddle together and work out what needs to be done to achieve the Sprint Goal.
I don’t care if you did the Health Check in the morning. I don’t care about the BAU work. I only care what helped make progress towards the goal. I don’t care if you did the Health Check in the morning. I don’t care about the BAU work. I only care what helped make progress towards the goal.

I have heard of a team that do the ‘Huddle’ to work out what they are going to do. Then the Scrum Master or Product Owner or Manager comes in and they then do the ‘Stand Up’. The ‘Huddle’ in this instance would have sufficed. The Scrum Master/Product Owner/Manager do not need to be involved.

Also note, that the Daily Scrum does not need to be done “Standing”. The “Daily Standup” is an expression from Extreme Programming. Not Scrum. If you want to do it sitting down, go right ahead, but saying that, by “Standing Up” you are in an uncomfortable position and more likely to have a shorter rather than longer meeting thus keeping within the 15 minute time-box.

The Development Team uses the Daily Scrum to inspect progress towards the Sprint Goal, and to inspect how the progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimized the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal, and to create the anticipated Increment at the end of the Sprint. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adopt, or re plan, the rest of the Sprint work.

Thus is a formal chance for the Development Team to do something if the plan goes haywire. Rather than continue blindly following the plan./ Do something about it!

Look – Re-assess – Re-plan – Implement.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15 minute time box.

A test to try to see if the Daily Scrum is a status meeting rather than a planning meeting is to tell the Scrum Master to piss off! But do this after the team is ready and understands what needs to be done.

Another test is to see if the Daily Scrum does not happen if the Scrum Master/Manager is not present. If they are not present, then the team does not feel that they need to get together to discuss the situation. Therefore they only see the Daily Scrum as a status update.

A Scrum Master enforces the rule that only the Development Team members participate in the Daily Scrum.

Daily Scrums improve communication, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision making, and improve the Development Teams level of knowledge. This is a key inspect and adapt meeting.

Daily Scrums may not work if everyone is doing their own thing as there is no need for collaboration. For example, Team member John is working on Project A. Jane is working on Project B. David is doing BAU work. Simon is working on an internal piece of work etc. 
The question is, in this situation, which occurs quite frequently in business, are these people really working as a team?

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the increment and adapt the Product Backlog if needed. 
During the Sprint Review, the Scrum Team and Stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next thing that could be done to optimize value.
This is an informal meeting, not a status meeting, and the presentations of the increment is intended to elicit feedback and foster collaborations.

This is a set time to get feedback from the stakeholders. With traditional development, stakeholders get feedback at the end of the project. This is usually too late for the stakeholders to make changes – at least without significant costs. Therefore the Sprint Review enforces the Stakeholders to review at regular intervals. It also does not mean that this is the only time that Stakeholders can give feedback. Feedback may be sought at any time. In fact the more frequent the better, but it should be at a frequency not to interfere with the work.

This is at most a four hour meeting for one month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time box.

Again another time boxed meeting. The Scrum Master is not the one running the show. They are the event planner. They make sure the event takes place. The Scrum Master helps everyone. Team members, product owner and stakeholders understand the purpose of the event. They may help direct the event, but the content is all Product Owner and Team.

The Sprint Review includes the following elements:

  • Attendees include the Scrum Team and Key Stakeholders invited by the Product Owner.

Key Stakeholders should be those who:

  • Pay for the work done so they can see where their money is going.
  • Those who will use the product because they will have to live with the result and thus should have a say.
  • Anyone else directly involved with the product.

You do not want people unrelated coming along like the whole company, you also don’t want walk ins, only those invited by the Product Owner. This is also not a Town Hall, keep the group small and relevant.

  • The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”.

Full transparency here. No hiding half done work by not showing that feature. Show everything.
Done is based on the “Definition of Done”.

By showing what isn’t done, if stakeholders get angry, this will lead to the team “hiding” stuff. Hiding stuff means that the Stakeholders do not see reality and thus cannot make proper decisions. These decisions then affect the Development Team, it could be in the form of more work, new work etc before previous work is completed. The only way for the Development Team to “Catch up” is to work longer hours, or produce shoddy work. Neither of which leads to a good outcome.

The Development Team discusses what went well during the Sprint, what problems they ran into, and how those problems were solved.

More transparency. This time from the Development Team. By going through the development process, the Stakeholders can appreciate the work the Development Team went through. It also helps the Development Team take pride in their work. Rather than just showing what was done, they share the “struggle” they had to get the Increment done. A Developer that takes pride in their work is more likely to be engaged.

  • The Development Team demonstrates the work that has been “done” and answers questions about the increment.

Show the Stakeholders the progress and let them see so they can give better feedback. An even better method for the demonstration is to allow the Stakeholders to do the demonstration themselves with guidance from the Development Team. Do not try to avoid bugs. Show them so the Stakeholders are aware of them. Use this as an opportunity to find the “faults” rather than just show the progress. By finding the faults, you know where your improvement needs to focus.

This is where the term “Showcase” comes from. It becomes a  “Show and Tell”. A Showcase does not help the product get better which is the goal of the Sprint Review.

  • The Product Owner discusses the Product Backlog as it stands. He or She projects likely target and delivery dates based on progress to date (if needed).

This is to give transparency to the Stakeholders so they have a rough guess as to when the product will be finished or the feature they are interested in is finished.
Based on the work to date, completion of the Backlog can be determined based on current progress. Such as Burn down charts.
If for example progress is slow and delivery dates could be missed, the Stakeholders can discuss dropping features that are no longer required.
Ultimately though, the final decision rests with the Product Owner.

Target and Delivery dates should not be arbitrary. For example set a date to get the team to work faster. This adds stress to the overall process. Leading to teams working late into the night to meet a false deadline only to find out that is made no difference. This becomes very demoralizing for the team. It also shows disrespect for the developers as there is insinuation that the developers are not working to their best capability.

  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.

The key here is collaboration. Everyone gets a voice. Everyone has input.

  • Review of how the Market Place or Potential use of the Product might have changed, what is the most valuable thing to do next; and

Things can changes, the Stakeholders, Product Owner may reject what has been done. This is always a possibility. Not only for new work, but for work already done.

  • Review of the timeline, budget, potential capabilities, and market place for the next anticipated release of functionality or capability of the product.

This may include canning the project/work. If enough value has been reached, then work can stop.
This needs to be taken into account.

The result of the Sprint Review is a revised Product Backlog that defines the probably Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

This is a deliverable of the Sprint Review. It is up to the Product Owner now to determine to include the new items and their subsequent priority. This is just one aspect of the Product Backlog. These items may need further grooming by the Product Owner and the Development Team.
Everything is up for re-ordering, removal or addition. Nothing is fixed.
The Plan Potentially changes yet again!

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvement to be enacted during the next Sprint.

This is part of the final portion of the Plan->Do->Check/Study->Act cycle. It is a formal time when the team reviews how they have worked. The output should be a plan (or experiment) on a way to improve the current situation. It doesn’t have to be a big change, but there should be a change. The requirement for chance is to prevent stagnation.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprint. For shorter Sprints, the event is usually shorter.

Again time boxed to a maximum time.
Two week sprints, usually 1 ½ hours is allocated.

The Scrum Master ensures the event takes place and that attendants understand its purpose.

This is an interesting statement. It means that the Retrospective is for the Team, by the Team. It is not the Scrum Masters role to “Run” the Retrospective. They merely facilitate the Retrospective.

The Scrum Master ensures that the meeting is positive and productive.

Retros are just a waste of time.

If the feeling by the Team as a whole is that the Retrospective is a waste of time – do something about it! Discuss why it is a waste of time and look at ways to improve them.

One common mistake is to skip the Retrospective when it is a “waste” of time. This only “hides” the problem, it does not address the problem. Scrum’s purpose is to expose problems, in this case a meeting for improvement that doesn’t do anything. It is up to the Team to actively make the meeting useful. Scrum can’t fix passivity.

The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum Process.

Interesting note, there is no mention of the 3 questions in a retrospective anymore.

  • What went well during the Sprint?
  • What didn’t go well during the Sprint?
  • What needs improving?

While these questions are answered – they are not directly asked. The answers must be encouraged from the team.

What if people have nothing to say? They shouldn’t be made to talk.

That is all well and good, but I cannot tell the difference between not having something to say and not saying anything because…

  • You are afraid to
  • You are intimidated not to say something because the environment isn’t safe.
  • You think no one cares about your view.
  • You’re pissed off.
  • etc

The only way to be sure is encouragement of participation to bring the issues out in the open and make sure it is safe to do so.

The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process and tools.

This isn’t a time to go through the work output itself, but how the work was done.

  • How the team worked together, if well
  • Any experiments on how to work. i.e. making work visible, limiting Work In Progress (WIP), Working from home, etc.

The Japanese word Hansei comes to mind. Acknowledge ones mistakes and pledge improvement.

  •  Identify and order the major items that went well and potential improvements.

What did we do well that we don’t want to forget?
What did do well that we can exploit to improve other aspects of the process?

  • Create a plan for implementing improvements to the way the Scrum Team does its work.

This I think is the most missed out thing with Retrospectives. Planning the improvement. If you do not plan to improve, the Retrospective becomes useless. It is all well and good pointing out areas that need improvement, but not doing the improvement guarantees failure.

If you do plan, plan it as an experiment. Have a hypothesis, determine the expected result and actually see if the result is reached. Determine a timeline to review. It could be the next day, week, sprint, month, but you need that review.

The Scrum Master encourages the Scrum Team to improve, within the Scrum Process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.

This gives you permission to make things better. Challenge the status quo and have fun doing it.

This gives permission for those in “death” Scrum to challenge their situation. I know I don’t find “Death Marches” fun. Maybe you do? but I don’t.

Change things up to make them enjoyable. If its not, you are doing Scrum wrong.

During the Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with Product or Organisation standards.

This is self inspection of the work process, the Sprint Review covers the improvement of the work output.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that they will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaption to the inspection of the Scrum Team itself.

Self Improvement

Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on the Inspection and Adaptation.

I don’t like the statement “Improvements may be implemented at any time”. This can insinuate that they may be put off due to “other” work and thus never be implemented. I think an additional statement that improvements should be “tested” as soon as possible. I realize that improvements may need to be put off , but adding “as soon as possible” means they should not sit on the Backlog forever. Also, by specifying “tested” acknowledges the fact that an improvement may not actually make an improvement. Thus testing, even a small test will help verify this before implementing a large unweildy improvement.


That was a long section. We’re on the home stretch.

I actually only got this far when I was studying for my PSM certification. I had gone through the Scrum guide so often, and I decided to wing the test and try. Low and behold I passed. 
This doesn’t mean I’ll stop here for this decomposition. I still think the exercise is worth while doing, so over the next few weeks I’ll be doing part 4. At the end of part 4, I’ll also include the written version as an attachment for anyone interested. Yes, I wrote the Scrum guide out by hand!

Let me know in the comments if you have found this useful.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.