Ask a question like this, and you're likely to get a numberline as an answer...

"two weeks"
"three weeks"
"four weeks"
"one week"
"15 calendar days"
or, in general, n+1 answers for every n people asked.

Which is the correct answer for my team?

Turns out that it's all. Or none. Or one of these. Or sometimes two.. There are a variety of factors that can help determine what the "right" length of a sprint is for your team. And, it does vary by team. Some organizations have one team on a two-week cycle, and another team on a 4-week cycle. They coincide, so deliverables can be coordinated, and intra-team dependencies can be predicted. Other teams swear that the original proposed Scrum cycle should be 4 weeks, and that's that. Most teams are open to doing what works. However I have seen organizations prescribe to the team how long their delivery cycle should be, for one reason or another. This dictated timeframe seems to be a bit less effective than getting the team to decide. Also, larger teams tend to have more problems with estimation, as do very small teams. More than 7 or less than 4 on a Scrum team seem to be the limits for most effective delivery, in my experience.

Now then, there are certainly pro's and con's for each of the cycle lengths. A longer cycle means more stories can be included, but that the feedback cycle of estimation vs. delivery is longer and thus not as able to hone in on velocity. Too short a cycle sometimes feels like thrashing, and that not enough complete, thin slices of end-to-end functionality can be accomplished. Remember at all times, that a completed "done done done" story is "potentially shippable."

The truly completed "done done done" story is rare in my experience as an actual shippable unit, but that's an article of its own on how to pick and adhere to DONE criteria.

Let me discuss the merits and drawbacks of each of the cycle lengths above. For the sake of discussion, I will assume a Scrum team of 7, 4 developers, 2 testers, and a project manager. I personally have tried each and every one of these iteration lengths, so I do have the perspective of experience (on a small team). Your mileage of course may vary...

Two Week Cycle
This cycle length has been in my experience the sweet spot for a small, experienced Scrum team. It is just big enough to get "real work" done each iteration, and small enough that the feedback on estimation is frequent enough to get closer on story estimation and velocity determination. I have also found that this relatively short cycle is good for preventing "hijacking" of a sprint by one or more stakeholders, management, or others that work outside the Scrum framework. Almost always, a sprint in progress can be completed even in the face of changing requirements, or stakeholder directions. "We can start that the end of this week" or at the latest "the end of next week" is almost always a fine response to these winds of change. The time spent planning and demonstrating (meetings in general) is a good middle ground, and payback for this time spent is usually pretty good. The typical planning meeting is 4 hours, first thing Monday, and the demo is 1 hour, and the retrospective 1 hour, at the end of the day the second Friday. I am a big fan of sprints that start on Monday and end on Friday, rather than the middle of the week. Mid-week sprint endings sometimes allow for "between sprints" time which I don't tend to like, as the things getting done aren't accounted for in the velocity of either the prior or following sprint.

Three Week Cycle
Three weeks is a good compromise between those who want faster, and those who want bigger chunks of work done. However, I am still of the opinion that for most teams, there is too much wiggle room in 15 business days. Sometimes estimates are padded. Sometimes people end up working on things not on the backlog. Estimates tend to be farther off, because there is a perception that there is more time available to get things done. For a disciplined, experienced Scrum team that has worked at least 4 sprints together, this might be a very workable option. Provided that the organization plays by the Scrum rules, that the team keeps estimates to realistic values, and that the team is truly able to break down stories into small tasks.

Four Week Cycle
Most of the 4-week teams I have seen have ended up going back to a mini-waterfall approach. The first week tends to be design and investigation stories and tasks, a couple weeks of cranking out code, and the last week of testing, finding and fixing bugs. Not that it has to be that way, but that has been what I have most commonly seen. I think the reasoning was that the teams perhaps were not as experienced with Scrum, and the number of days left a perception that there was a lot of time to do things "the old way." Also, I have seen sprints hijacked by various issues and people, and totally taken sideways due to the length of the time. Feedback loop is much more difficult to perceive for most of the team, and as such, estimation may not just stay the same, it may get worse. Tasks tend to be lumped into large blocks of 15 hours, 20 hours, or more. A typical task on an experienced team with good estimation is not often over 4 hours, and never over 10 hours. These teams tend to be able to peg the stories for story points more accurately, and are able to deliver the stories as complete. This iteration length doesn't seem to work well, in my experience.

One Week Cycle
"How can you expect us to get anything of business value done in just one week? Especially given the Done criteria for potentially shippable?"
I think that's what I said anyway. My team was on a 2 week cycle, but we didn't have much experience with Scrum at the time. We were having lots of issues trying to break stories down into tasks. I recall several 40, 30, and other double-digit task estimates. They were just too big. We couldn't figure out how to break them down further. Planning sessions were a nightmare, lots of arguments about task breakdowns, and estimates. Fortunately we had an agile coach who suggested that we ratchet the iteration down to a 1-week period. At first, this seemed totally counter-intuitive to us. Shorter iterations? Wouldn't that make it even harder to break down tasks? As it turned out, that wasn't the case. We had to break our stories up from the epic stories we were using to actual user stories that delivered an increment of functionality that had business value. That was just the thing we needed to figure out what we couldn't do in the 2 week cycle. We tried one-week iterations for several weeks, and got a lot better at breaking stories and tasks down into smaller pieces. We as a team decided then that it was too much overhead to have a planning meeting, a retrospective, and a demo every single week. The stakeholders didn't really understand, and what we were demonstrating was such a small increment that they were starting to think that the project was just dragging out in delivering small pieces. The two week cycle was a good return on the time spent planning and demonstrating, vs. the time spent actually delivering work.

In the end, it should be up to the team to figure out what works best for them - given some input from the corporate culture and stakeholders. New teams just starting out with Scrum should perhaps plan to try first two sprints each of 2 weeks, then two for 3 weeks, and compare results. By the end of the 4th sprint, the team should have some reasonable idea of what would yield the greatest velocity. If there isn't a choice for iteration length and it's prescribed, you'll probably have to just make it work. In any case, try to avoid the con's above and see if you can get your scrum master to push back a bit on the powers that be and let the team have a bit of freedom to see what works best for all. Scrum should be a collaboration, so if at all possible, do the best you can at making sure everyone has their input represented and just hold the team accountable and let the team manage their own delivery.

Everyone keeps asking me about it, so here it is...
So you want to know about threat modeling? Congratulations, you have taken the first step toward software security. Software security should be the first thing we think about when we write software, but somehow it ends up being the last thing in a lot of cases. We should really be designing software with security as Feature 0. A Threat model is a nice element of an overall security plan, which really should be figured out before code line 1 gets written. This article gives a basic overview of how to create a Threat Model document, which can be used as a basis for a security plan for the system.

What is a Threat Model?
A Threat Model is a Document. The document describes a system in more or less a standardized way, so people can easily understand the system's overall architecture and design, and how it functions - from a security perspective.
A typical Threat Model Includes:

• Architectural Components
• Data flows
• Points of Entry
• Possible Attack Vectors or Scenarios
• Remedies or Counters to the Threats

How-to create a Threat Model
We can work backward from the goal: Ship secure software. To do this, we need to eliminate or mitigate security threats. To find these threats, we need to identify what's important to us, and how it can be used (for us and against us). We need to be specific about what we have that needs protection. Only then can we be clear about how to protect. We can use a Dataflow Diagram to help us identify these things in our system. Here is the suggested process:

1. Create a Dataflow Diagram
   1. See my separate post here: How to create a Dataflow Diagram
2. Identify the protected resources (Assets) that are of value to us.
   1. Everything on the DFD is an asset. Every dataflow, every process, interactor, and data store.
   2. Servers may be assets, as well as their operating systems, and other software on them.
   3. There may be intangible assets as well, such as bandwidth, or industry reputation. Imagine the damage if a security company's web server got owned by a hacker.
   4. What other specific things for the organization might be of value?
      
3. Identify the Entry Points - all places where data can enter the system.
   1. Entry points are more than just services listening on ports.
   2. Input or data files
   3. RSS feeds or external data feeds
      
   4. Configuration files or business rules engines
   5. Unintended services left running on the server
      
4. Locate the Trust-Level boundaries.
   1. Where are there components that communicate with each other at different levels of trust?
   2. Server and client are definitely different trust levels...
   3. Consider server boundaries
   4. process boundaries
   5. application boundaries
      
5. Brainstorm Threats
   1. Get the whole team together (developers, testers, program managers, and even management) and discuss each of the things on the dataflow diagram, to see what if anything there is that is possible, or potentially a threat. Don't exclude any ideas at this point, just write it all down. We can eliminate and prioritize later.
   2. Keep in mind that each of the asset types has a set list of potential threat vectors for it, these can be used to examine each asset for a thorough evaluation.
      1. Threat types are [STRIDE] Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Escalation of privilege.
         
   3. No threat is to big, to small, or too outlandish to record. "Someone could bribe our sysadmin for the root password" is still a valid threat...
   4. It’s sometimes difficult to identify the threats. We can use a trick to find threats by identifying them from mitigations:
      “We use SSL to protect the data flow between the server and the user.”
      That’s a Mitigation… but what’s the Threat? Man-in-the-middle, data disclosure, etc.
      How about “SSL authenticates the server.” => Threat: “Hacker could impersonate our server”
      
6. Refactor, revise, amend, prioritize, categorize Threat list.
   1. Go through the list, and evaluate each of the suggestions, giving each a priority. If there are non-valuable suggestions, discard them at this time.
   2. Threats need to be linked to a asset(s), and entry point(s)
      
7. Brainstorm mitigations to threats, starting with the highest priority
   1. Mitigations include firewalls, SSL encryption, PKI security, certificates, and the like.
   2. Sometimes a mitigation for a denial of service threat is to increase the performance of the application, such that the expensive issue is no longer expensive. Other times we can mitigate by throttling, or something akin.
   3. Mitigation Examples:
      1. Code Reviews - #1 most effective means to prevent security defects
      2. SSL protects in-transit data and authenticates the server (does NOT authenticate the client…)
      3. Input validation for user input
      4. XSD validation for XML documents
      5. Use Stored Procedures to access all data
      6. Access Control Lists prevent unintended access
      7. Firewalls prevent unintended access
      8. Least-Privilege accounts lower the amount of potential damage a compromise can effect
      9. Bandwidth Throttling can help prevent DOS attacks.
         
8. Document all of these things in a "standardized template"
   1. Different organizations use different templates, I don't have a good example yet but when I do I will post it.
      
9. Present and Review the threat model with the team producing the software.
   1. Everyone should be on the same page. The threat model is a great way for everyone to come to a common understanding of the architecture and focus on the things that can keep it secure.
      
10. Keep the document secured, and release it only on a need-to-know basis.
    1. This document tells everyone what we know are potential shortcomings of our system. Keep it under wraps!
    2. Only allow access to specific personnel, and make it a short list.
       
11. Review and Revise this document EACH SPRINT.
    1. Even if no new features are shipped in a sprint, it is worth reviewing the model document, just to make sure it is still accurate and relevant.
    2. If there ever is a security incident, the information most definitely should be added to the Threat Model document. One would wonder at this point what in the process of security and system design let this flaw in. This would be an opportunity to evaluate the design process and make some changes.
12. Use the Threat Model as a guide to designing and developing software
    1. Now that you have a basis to start, use it as a springboard to design and implement better software!
       

Using this method, we should be able to produce a document that gives us a base starting point to talk about security of our system, and help even non-technical people get on the same page to understand what any potential issues are. With this understanding of the system, we can then move forward and focus on the areas that are most important.

There are some tools available, here is one from Microsoft. It has some pro's and con's. There isn't much else out there that I know of at the moment in terms of tools that help with Threat Modeling.

Here is also a nice article on MSDN about Threat Modeling that is similar to this method I describe.

PS - some terms used in Threat Modeling
Terminology

• Asset        (Protected Resource) Something we have that someone might want to get
• DREAD        Ranking system – how serious is it
  • Damage, Reproducibility, Exploitability, Affected users, Discoverability
• Entry Point        Interface between the system and the world
• Exploit        Using a vulnerability to compromise something
• External Interactor    an entity not in scope for this threat model
• Mitigation        lessening impact of or elimination of a threat
• Penetration Test    third party is hired to find a way to hack in
• Vulnerability        a security flaw that could be exploited
• Vector        the mechanism of entry
• STRIDE        Classification system – what kind of threat is it
  • Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege
• Threat        an adversary’s goal
  
  

Definition: Technical Debt is a term that we in the Agile world use to describe things in the code that perhaps aren't engineered as well as they could (should) be. It can refer to many things, like areas in the code that we should probably refactor to make them more readable, poorly performing code, obsolete or clunky architecture, encapsulation abstraction, or other class problems, or the like. It's debt because we know about it, we "owe" it to be done, but are focusing on other things instead.

Technical debt is the avoidance of doing work that we would otherwise do in the course of doing our best practices in engineering. It's a fact of life that most every Agile team has to deal with, in my experience. I find that there are various means of "dealing with" technical debt, some of which I will discuss below as a matter of practicality. However, I see it really as a symptom of a deeper problem. The team isn't finding good engineering as valuable as completing stories could be the underlying problem.

Teams can be pressured to deliver more than they should (this is common), and as such, could be focused on delivering the current sprint's stories rather than fixing things they find that are not as they should be. The team also could be creating more technical debt for itself by not focusing on good engineering in the first place. When junior people design things, sometimes they don't address all the points of performance and code maintainability. Trade-offs are made that can end up causing lots of rework later.

The concept of Agile software development, is heavily based on refactoring. Sometimes I find that teams use refactoring with a little "r" when they should be Refactoring. They make small internal changes, but are reluctant to change overall design, even when it is truly warranted. When we add a new feature, sometimes the design needs to change to accommodate it. THIS IS EXPECTED behavior in an Agile development process. Yet, time after time I hear developers say "well, I don't want to change all that NOW..." when that's really exactly what they should be doing. The concept of iterative development should be allowing us to ship software at the end of every cycle, and we really can't consider the software shippable if it has these poor designs still left over from earlier days.

Refactoring the design shouldn't be catastrophic though. But, there is always some impact that is almost always fundamentally left out when planning. Imagine we have an apple, and we need to add some cherries to it in this sprint. We might just smash the cherries on the outside of it, and call it good. But that would leave us a lumpy ugly mess... Rather, we might take another approach, and put the apple and the cherries all in a blender, and pour the mix into a new shape mold and freeze it. The new shape will be smooth and round, yet it will encompass the new features of having both apple and cherry flavors. It's a dumb example, but you get the idea. Refactoring can take many forms.

Handling Technical Debt
Now, I have been on a few Agile teams and I am a realist. Technical debt is most certainly here to stay. We just aren't in an ideal world, and we can't always take the time we really need to make sure that the iteration's deliverable is as pristine as it should be. So, now how can we handle this debt in a practical way?

Here are some ways I have seen teams deal with Technical Debt:

1. Ignore it.
   1. This don't work so good, in my opinion, but yes I have actually seen it done. It works, so we'll use it as-is.
2. TODO it.
   1. //TODO in the code is a flag that there is something more that needs attention. Also, //FIXFIX and //BUGBUG are others I have seen. Some of the tools give us mechanisms to flag these as work items, but in my practical experience this is just about the same as #1. Nobody ever gets back to these things to fix them. They just lose visibility and get buried. Not very effective in my book.
      
3. Backlog it.
   1. Create a backlog item called Technical Debt. Each instance where something needs attention is recorded as a task for this story. They can be estimated, and prioritized. Backlog items have visibility, so they don't get lost. Here is the problem - Technical debt now CAN be prioritized. And, it usually is - right to the bottom of the list. This really doesn't solve the issue either, unless you have a product owner who is savvy enough to know that good engineering means happier customers, developer, and management in the long run.
      
4. Bug it.
   1. Log a bug for each Technical Debt item discovered. This is probably the most effective means I have yet seen for the actual reduction or elimination of technical debt. In reality, I think this is the most appropriate. The new story requires changes that just haven't been made. It's not really "done" until this is taken care of. Ongoing maintenance of code should have an appropriate stakeholder with a voice in the Product Owner's scope of attention.
      
5. Job-Jar it.
   1. Put it into the bucket of things that need to be done but aren't on either the sprint or product backlogs. I think this is marginally effective, because nobody should technically ever have time to get to this stuff, they really should be pulling things off the product backlog onto the sprint backlog. But, I thought I'd mention this concept since someone brought it up.

Are there other ways to deal with Technical Debt? What ways have you had success? Please leave me a comment and let me know.

Security has always been a challenge in software development. Being in an environment that has rapid ship cycles and iterative development does add challenges of its own when it comes to security.

Here are a few of the key concepts I intend to flesh out in the next few weeks:

• Security Requirements
• how to come up with security stories
• how much is enough?
• how much is too much?
  
• Using automated tools
• what tools are available
• MetaSploit - multiple vulnerabilities: http://www.metasploit.com/
• Fiddler - HTTP/S proxy, inspector, injector, manipulator. Fun for the whole family. http://www.fiddlertool.com/
  
• WireShark - network protocol analyzer and sniffer: http://www.wireshark.org/
  
• various other network tools like Snort, RetinA, NetStumbler can be automated and scripted.
  
• use static code analysis tools, and pay attention to their results.
• I recommend also doing file and network fuzzing on system entry points, but don't have any good tool recommendations. Got some? Please leave comments!
  
• web site testing vs web service testing
• application testing
  
• how do the fit into automation frameworks
  
• Security Documentation (Threat Models)
• Designing in Security as Feature 0
• Iterative Threat Modeling
• Who Reads the Threat Model?
• How do we turn threat models into automated acceptance tests?
• security testing strategies
• white route (internal folks, given the internals of the system)
  
• black route (for-hire hackers, given only an objective to accomplish, and no system information)
• security-oriented code reviews
• how to train developers and testers to look for security defects
  
• security vs. performance
• Sometimes mitigations incur a performance hit. How do we avoid this, and what are some alternatives?
  

This is an Agile blog, so this is the first production release of this article ... More features (content) will become available over time, so stay tuned to this RSS feed for updates and new content, as they emerge.

As an agile developer, I think it's fair to say that there is a bit of pressure to deliver software on a regular basis. In order to do that effectively, I need to be able to produce readable code that my team members can understand, and vice versa.

Every org I've been a part of has its own quirks about what it will allow for coding standards. The worst is when there are no standards, or they aren't "enforced." Lots of shops have these cowboy coders that love to do things their own way. It doesn't matter to them that the whole team is going to have to read, understand, and potentially update the code they are writing. The concept of "collective code ownership" is lost on these folks.

What can we do to reign in these cowboys? I proposed a coding standards guideline. It specifies in some detail how code should be written and formatted. It specifies the style, structure, and conventions. I recommended that code follow these guidelines specifically, unless there was a "really good reason" why not. "Really good" reasons did NOT include the phrase "I just didn't like it" or "I have just always done it this way." Being set in ones ways is one thing but being a professional and being part of a team is another.

Does anyone have a practical solution to this issue? If so, I'd love to hear about it... please feel free to post a comment.

How do you handle bugs? There are many ways organizations handle bugs in software. I have what I think is a very workable approach, see if you agree.

The environment: The team is a dozen software developers and testers (total) and the project is run as a Scrum project. Iterations are 3 weeks.

Scenario 1:
QA is testing the build, and there is a bug discovered. The date/time field data that's entered in local time is stored in UTC, but the data comes back as UTC (not local) when retrieved.

1. QA logs a bug. Priority 2 Severity 2
2. Bug is assigned to the Product Owner for the team.
3. PO looks at the bug, and makes the call that the currently signed-off stories are more important than this bug.
4. The bug is estimated in story points by the team as 2 points.
   
5. The bug is put on the product backlog, prioritized along with the other bugs and stories.
6. The team can't "ship" the sprint's release with this bug outstanding, but the PO knows that they aren't planning a release for another two sprints anyway.

Scenario 2:
QA is testing the build and discovers that if a name is entered that is longer than 50 characters, the site crashes with an unhandled exception.

1. QA logs a bug, Priority 1 Severity 1
2. Bug is assigned to the Product Owner for the team.
3. PO knows that this bug is serious enough to warrant being fixed right away.
4. PO meets with the team, and the bug is estimated at 5 story points.
5. The team's velocity last sprint was 80, and they have committed to 78 points for this sprint. The team left only 2 points "spare" and didn't allocate time for bug fixes.
   
6. PO suggests that the bug be fixed this sprint, but the team does not feel they will have time enough to do that along with the other stories.
7. PO removes the lowest priority story from the sprint backlog, and replaces it with the bug instead.
8. The story goes back on the product backlog as the top story in priority.

There are also other permutations that may work in different organizations:

1. Abort the sprint, and replan a new sprint including the bug fix.
2. Allocate some time and time-box it just like a spike. The team may not be interested in working overtime, but try to negotiate it anyway. Most teams will want to fix bugs like this even if it means they work a few extra hours. Buy pizza.

The current team I am on doesn't follow these guidelines, and they insist that every single bug be fixed for every sprint, or the story can't be accepted as done. While I think this is a lofty goal, in my experience it just isn't practical. Maybe it's my old school days at Microsoft where "done" meant it was "code complete" but not "bug free." I think that Scrum gives us the ability to continue the current sprint and continue to develop the features as committed, and delay bug fixes until the next sprint. The only time when this doesn't work is the case where this sprint's story delivery is scheduled to be the release. And even in that case, most organizations allow a small window for last-minute fixes which could be used to take care of the bug.

If the developers are doing TDD, they won't be writing bugs in the first place... I see more than a handful of bugs per sprint at a clear process smell. In that case, the process should be evaluated to see why the bugs are being created in the first place. Is it unclear story descriptions? or more likely, is it a lack of testing in the functional, integration, and acceptance areas? Any way it goes, bugs seem to be a symptom, not the actual problem. Every bug I have written myself was due to a lack of a test for that area. Find a bug, write a test! Please make sure that your developers realize that when they estimate fixing bugs, that it should always include writing tests that first fail when the bug is present, then pass when the bug is corrected. Bugs should not be able to be resolved without at least a unit test to illustrate that they are really fixed.

Handling bugs can complicate a project manager's life, so if they are cropping up, be sure to address the root cause, and all will be happier.

OK, so this one isn't about agile. But, it's such an annoying pain point I thought I would share. And, I couldn't find much info on this error message out there in the ether.

Visual studio complains every time the solution is opened: "... discrepancy between the solution's source control information ..."

When using Team Foundation server for source control (also the same issue with VSS I presume), someone on my project decided it would be better to use the source control server's IP address in the project SccAuxPath entry, instead of the server's name. They may have been experiencing DNS issues, or something like that. I recommended to the team that if this were the case, and DNS was not dependable, to put the IP and the server name in their c:\WINDOWS\system32\drivers\etc\hosts table. This "discrepancy" confuses the poor little source control system, and it senses that there is a difference between the server's name (to which it has a TCP connection already) and the target destination specified in the project.

So, it checks out the file, expecting that it will have to change something. Then, it is able to connect using the IP, and everything's fine. Except, the files are left checked out with no changes.

 

Here is the fix:

 

simply change

    <SccAuxPath>http://10.10.10.10:8080</SccAuxPath>

to

    <SccAuxPath>http://TFSSERVER:8080</SccAuxPath>

and problem is solved.

 

Just remember that TFS is relatively easy to confuse... Now, just go ahead and retire TFS and use Subversion like the rest of us

scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word "but" when answering the question "Do you do SCRUM?"


You wouldn't want your surgeon to follow just *SOME* of the steps in that procedure you're getting, would you?

SCRUM works great, if you can just follow the (whole) program. It's not surprising how many organizations say they have failed using SCRUM, when they have only picked and choosen a few of the aspects to implement.
For those of you who need a 12-step program... and you know who you are...


1. Use a 2-week or 4-week sprint. 2-week preferred
2. Appoint a scrummaster who will hold the team accountable, AND also keep the wolves at bay.
3. Make sure the entire team is jointly accountable for the success of the project.
4. Have a prioritized product backlog ready before the sprint. This can include both bugs and features
5. Have a REAL planning meeting where the team commits to stories and they are thoughtfully tasked out and estimated.
6. Team members commit to stories, and then break them down into tiny pieces (tasks). If any estimates are over 4 hours, break them down further.
7. Do a daily stand-up. What did you do, what are you going to do, and what's blocking.
8. Don't do anything that's not estimated and in the sprint backlog.
9. Establish, post, and meet DONE criteria. It's only real if it's posted and visible to everyone.
10. Post a sprint backlog task burn-down chart and update it daily.
11. Keep the product owner in the loop at all times.
12. Hold a stakeholder review a the end of the sprint - this is the fun part!
(13) Then, have a retrospective meeting to discus what went well, what could use improvement, and action items.

That's SCRUM!
Now, you'll never have to be a SCRUMBUT again!