How much technical detail should we talk in Sprint Planning 2

Question

I'm working in a Scrum team, We have Sprint Planning 2 to breakdown backlog into technical tasks.

The team is pretty big around 12 developers, We can't split cause it's not under our control.

We already have architecture designed, But may not cover everything since the code base continues to evolve.

And when it's come to pull requests, Many pull requests shock me with the unexpected design.

We struggle with how much technical detail we should talk or provide before the team starts working.

If we go with too much detail, The discussion may not be accurate we will saw design changes during we hand-on and implement it.

If we go with more autonomous, Let people think of their solution, People come up with very different approaches compare to how it should be.

So question is,

How much level of detail we should talk in Sprint Planning 2 to make this better?

And any factors and ways to solve this problem?

Answer 1

I can't say for sure without being there in the team with you, but it sounds like you're expecting to come out of Sprint Planning with everything settled and in my experience, that doesn't often happen. I always liked Mike Cohn's answer that you should have the conversations necessary in order to start the sprint work. Similarly, you should go into the level of technical detail to start. In my experience, it is not uncommon to have discussions about what system the data likely resides in or the requirements around system redundancy, but if you're actually designing the implementation in Sprint Planning you're probably taking it further than is helpful.

Scrum is intended to be highly collaborative, with frequent discussions between team members throughout implementation. Designs that are out of the bounds of the architectural vision shouldn't come as late surprises. There are a lot of good practices out there that help with this, but some of the big ones that I encounter are:

Pair Programming (or even mob programming): I've done a fair amount of pair programming in my time and I know the drawbacks and frustrations, but if you're struggling to get the whole team on the same page on code or architectural standards, this approach means that the time from when they leave the agreed upon architecture until when another person catches it os 0 seconds, and you can't beat that.

Architectural Reviews: Whether it's programming or any other information, there is this strange assumption that because information is made available to people, they will know it. If you have an architectural design (or code standards, or UX standards, or anything else the team is expected to follow), don't assume they understand it. Take the time to really go through it together if you haven't. And if they submit a pull request that leaves the agreed standards, it may mean they didn't understand it. Approach it like a coach or a teacher and help them bridge the difference.

Throw It Out: If someone does work that doesn't meet standards (architecture, quality, anything), don't merge it. Companies are always afraid to "waste" work. But if you accept code that doesn't meet the standards, then you are making an explicit statement that the standards aren't that important.

Team Code Reviews: Many organizations treat code review as a check-off, and that may be fine for some of them. However, it's also an opportunity to share knowledge and expectations. In your situation, doing a few full-team code reviews a sprint might really help.

I want to acknowledge that most of these are "inefficient" with people's time. This is intentional. Scrum puts being effective first. Once the team is effective, then you worry about being efficient. The time you lose to things like team code reviews should be paid for by the time you don't spend going back and redesigning features to meet your architectural vision.

Answer 2

Just add to your sprint items like “create an agreed design for feature x”. This is given points, someone takes the task, creates a design and makes sure others agree. Next sprint “implement x according to design”.

Answer 3

Let me start by saying that there isn't a Sprint Planning 2 since the 2011 version of the Scrum Guide.

The WHAT (Sprint Planning 1) and the HOW (Sprint Planning 2) have been merged into only one Sprint Planning meeting in the 2013 version of the Scrum Guide (you should use the latest guide for implementing Scrum, as the new versions improve on the old from lessons learned). They were merged because most of the times you can't separate the two. The HOW might influence the WHAT. And trying to have them separated definitely decreases the collaboration that should exist between all Scrum team members (in a Sprint Planning 2 meeting, for example, the Product Owner is optional, but that isn't such a great idea because when discussing the HOW, the developers can still have questions and need to take decisions that only the Product Owner could provide an answer to).

With that being said, the architectural design decisions should not really be something to discuss at the Sprint Planning. Your problem is that you are trying to enforce the design as an OUTPUT of the planning meeting, when this is something that needs to be enforced as an INPUT of the planning meeting.

Everyone needs to contribute to a homogeneous design and architecture. If they don't, you should address why that is. Raise this issue at the next Retrospective meeting, then as a team figure out how to improve on it. Improving how you use Scrum doesn't just mean working on the process, but also on the technical practices. As others have pointed out, you can do that for example with code reviews. If the design does not match the architecture, then stop the story from being "Done". Make passing the code review a part of the "Definition of Done", and if some story doesn't pass the code review, it means it's not "Done".

Have architectural meetings, select proper rules for code review, do trainings if necessary, so that everyone understands the architecture and is on the same page design-wise. Then you won't have to worry about how much technical detail you should talk at the Sprint Planning. You will talk just enough to get a good confidence on the WHAT and the HOW and forecast enough work to meet the Sprint goal.

Answer 4

Sprint planning isn't a forum for technical implementation.

Usually, the tasks don't go into detail on the implementation.

For example (sample tasks for a story):

• Dev Implementation
• Dev Unit Test
• Dev Code Review

If you're having problems around technical implementation, then schedule another meeting. Call it Technical Story Planning. Only invite the developers. Go through each story and talk about how it would be implemented so everyone is on the same page. If you want to add addition details on the implementation, feel free to add them to the story as items under the development implementation task. The details code be notes or a word/pdf document or formal architecture documentation.

Answer 5

The Scrum Guide doesn't refer to a "Sprint Planning 2", but based on the question, I'm going to assume that you're referring to the portion of the Sprint Planning after the team has determined the Sprint Goal and selected the appropriate Product Backlog Items. In this part of the Sprint Planning event, the team works on a plan for how the work will be done and the goal will be met.

Unfortunately, there's no one answer to how much detail the team's plans and Sprint Backlog have at this point in time. It should be sufficient to give the team enough confidence that they have a plan that is likely to lead them toward achieving the Sprint Goal. What "sufficient", "enough confidence" and "likely" mean depend on your organization. Some teams and organizations are more tolerant of change and risk and can perform less planning. Other organizations have low tolerance for risk and the planning is likely to be more detailed. The only rule is the timebox for the Sprint Planning event, which is 8 hours. Note that the timebox holds regardless of your Sprint length, but Sprints that are less than one month in duration tend to be completed in less than 8 hours.

I'm unconvinced that the Sprint Planning and level of technical detail in planning is the problem. If the problem is that the work done by the team doesn't align with the architectural vision, that isn't something that must be addressed at Sprint Planning. It can be addressed in other means, ranging from ensuring appropriate communication of what the architectural vision is and getting buy-in from all of the individuals to more pair and mob design and implementation to more peer review of work. These can be used to develop, teach, and enforce the architectural vision and to respond to cases where the vision doesn't match reality.

Instead of looking at how much up-front design to do, my recommendation would be ways to push design across the entire Sprint and get the whole team involved in continuous refinement of and agreement to architectural decisions as they are being made.

Answer 6

And when it's come to pull requests, Many pull requests shock me with the unexpected design.

If we go with more autonomous, Let people think of their solution, People come up with very different approaches compare to how it should be.

Your statements seemingly imply an expectation that the developers have full autonomy on everything that was not explicitly discussed during the sprint planning. That really shouldn't be the case.

• If we go with too much detail, The discussion may not be accurate we will saw design changes during we hand-on and implement it.
• If we go with more autonomous, Let people think of their solution, People come up with very different approaches compare to how it should be.

Trying to notarize every design decision before starting to work on it is micromanagement. But leaving developers with full individual autonomy is an absolute lack of management. Healthy management lies inbetween the two extremes, there is a balance to be struck here.

Sprint plannings focus on what should be worked on. How it should be implemented is a completely different discussion. It makes no sense to solve the problem (i.e. deciding the exact implementation) before you start working on the problem (i.e. during the sprint itself).

Big picture - before the sprint planning

To be fair, there is some overlap here. For larger tasks, splitting it into separate tasks often requires at least a big picture understanding of the architecture. Big picture architectural decisions should (a) not be autonomously decided by just any developer and (b) be made either before the sprint planning (e.g. new features) or in some fringe cases during the sprint planning (e.g. when deriving tasks from an existing backlog).

To save on time, it's often more efficient to let the architects/senior devs/lead devs preliminarily address the big picture decisions on their own time before you involve the other developers.

If the big picture decisions end up being flawed, and you only notice this at the end of the sprint, then you've got bigger fish to fry. There's no one-size-fits-all solution to any and all issues that could lead to a bad architecture, other than ensuring that you've put the best people up to the task.

Little picture - after the sprint planning

When the sprint planning is done, developers start picking up the tasks. They will be required to make some low level design decisions on how to implement the required change.

However, that doesn't mean that the low level design is the Wild West. Developers still have to adhere to approaches that are actually applicable, apply good practice, fit with the existing codebase and use their common sense.

That doesn't make it impossible for a developer to go astray (unintentionally), but there should be several systems in place that should catch this early on. Code reviews are the last line of defense for bad design decisions. However, as you're pointing out, they happen at the end of the sprint and if something went wrong early on, it can lead to a lot of reworking.

Therefore, your team should be relying on checks and balances that occur during the sprint, such as:

• Developers should apply some reasonable self-assessment to coordinate complex implementations with other team members, whether that's a lead dev, mentor, or peer. This can be a simple "hey I'm going to use X for task Y" can be a very valuable sanity check. I'm not saying that developers should know when they're making a mistake (because mistakes are by definition made without realizing they're mistakes), but developers should be able to have a sort of spidey sense for when they need to sanity check the decisions they're making.
• Daily standups enforce similar sanity checks by having developers regularly summarize their tasks. Alert senior/lead developers should be on the lookout for developers whose summary implies either a bad design decision or overall uncertainty about the design.
• Junior developers or those who have historically been known to walk an unusual design path should be followed up on more closely, at least when working on a feature-building (as opposed to bugfixing) task.
• Pair programming (even if only parttime) can help reduce bad design decisions, but be wary of pairing off two juniors (or those who have historically been known to walk an unusual design path) without any oversight.
• In certain cases, it can be valuable to have a midway code review. I often do these when dealing with a task that has me first set up a design and then spend some time implementing it. When having set up the design, I already open this up for code review while I work on the further implementation. Any bad design decisions can thus be caught earlier (assuming someone actually reviews it of course).

If all checks and balances fail you, and you still end up with pull requests that "shock you with the unexpected design", then you're going to have to rely on retrospectives to figure out what went wrong, and how to prevent it from happening again.
There is no hard and fast solution here - retrospectives are intended specifically for you to acknowledge issues and find tailored solutions to prevent them from reoccuring. Possible solutions include:

• Realizing that a certain developer lacks certain knowledge, and providing them with the proper resources to learn and grow
• Amending the checks and balances to catch this issue earlier next time it occurs
• Sometimes it suffices for a team to talk through a miscommunication and learn from it, it doesn't always require actions from management.

This is not a complete list - you're going to have to tailor solutions to your particular problems.