normal two-week Sprint has nine working days or 45 available hours per person (ten five-hour ideal days minus one day for end-of-Sprint demo and Sprint retro
Usually the suggestion is that everybody must put at least one note on the boat, but no more than three.
The burn-down chart should be shown to the team daily. It gives an accurate indication of how much work is done, and it does a good job of predicting whether the team will finish all of the work it committed to for the current iteration.
During the Sprint Planning meeting, the team looks at the story and breaks it into tasks. Tasks are segments of work and are figured in hours. But not as you would think. Agile teams work in “ideal days.”...
In ideal day for a software worker is about five hours...
Truth be told, we never sit down and spend eight hours a day banging out code or testing. We go to meetings, deal with our email, talk to our teammates about design or trouble we are having with what we are working on, attend town hall meetings, get coffee, visit the restroom, and a bunch of other stuff I won't detail here. The five hours should reflect how much time we spend actually working on user stories a day.
In Agile it’s much easier — the standard is “zero defects.”...
The idea is that a defect does not increase in value over time, but it does increase in cost, exponentially.
As a team member, you should always be looking at how you can help the team achieve the Sprint goals. That might mean that you jump in and do some testing or help write some code for a story that hasn’t been completed yet.
Managing work in progress (WIP) is a sign of maturity. For some reason, most people want to start working on everything at once. I call this the curse of multitasking. Yes, we live in a time that seems to demand that we multitask, but in my mind, it's more valuable to get stuff done. Getting stuff done requires that we focus...
It's better to have fifty percent of your stories one hundred percent done than one hundred percent of your stories fifty percent done.
Both defects and technical debt should not be assigned story points. They should negatively affect velocity and give an accurate picture of how fast the team is getting features done.
Waterfall encourages a team to hide the bad stuff. Scrum will expose the bad stuff… quickly. The beauty of this is that once the bad stuff is exposed, the team can easily remove it because following Agile methodology requires a constant striving to get better.
Stories always need to be written from the customer’s point of view...
Personas are a powerful tool that the Scrum Master and Product Owner can use to keep the team focused on the customer’s perspective.
Scrum Harmony... there are the levels that you will pass through:
... it is a simple example of the stages a team will go through when learning a new discipline.
Tech lead, or architect they should be working with, or preferably part of the architecture team to get architecture defined in the Backlog...
“A spike is a small story you use to go off and do research. I usually insist that a spike not take up a whole Sprint. The result of a spike should be enough information to write stories.”...
Scrum relies on what is called emergent architecture. Emergent architecture emerges (hence the name) as work is done, and comes from within the Scrum team. It is usually discovered during story refinement.
That’s why we have an architecture team here. Their job is to work with Scrum teams and to influence how architecture evolves.
The PO will tell you what she wants, but it’s up to you guys — the TEAM — to decide how to turn the PO’s idea into working product. Every decision belongs to the team. From training requirements to what coding language to use. A Scrum team owns what it works on.”... Some of you need to find your voice and speak up. No matter what you say, getting involved adds perspective and information to the conversation
Adding or removing members is disruptive and should be avoided if possible. Instead of disrupting the team, move work to the team. If the work is important enough to break a team up, consider having the whole team do it. Moving work to the team enables the team to stay together and the business to meet its needs.
The rule is that you fix defects in the iteration they are found in. If stories need to be removed from the Sprint and put back in the Backlog to account for the time needed to fix defects, so be it. Sometimes it’s helpful to look at a situation from a different perspective to fully understand the impact.
Coaching is like a muscle; you use it or you lose it. As I’ve said before in this book, there is a difference between coaching and teaching and mentoring. There is also a difference between Agile coaching and professional coaching. Agile coaching is where you help folks with their Agile competency and skills. The goal of professional coaching is to help individuals improve performance.
I’ve heard the Agile rituals (stand-ups, Sprint Planning, Retrospectives, and so on) described as distractions that get in the way of “real” development work. Um… no. These meetings are not “overhead.” They are there to provide the structure and rhythm necessary for work to get done, and for important information and updates to be communicated between team members. Decisions about direction are discussed and commitments are made to each other. The meetings allow the entire team to participate, collaborate, and (dare I say) self-organize.
Not finishing stories in a Sprint makes it tempting to fall back into Waterfall-style behaviors. Remember, the idea is to deliver working software every Sprint. Allowing stories to slip will not allow the team to demo the minimally viable product that they committed to delivering. It also creates a domino effect. When a story slips to the next Sprint, there is a good chance that the team will not be able to finish all of the stories in that next Sprint. So the team does not complete all of the stories again. Stories slip again, and again, and again...
There is also the issue of taking too much time talking about stories and not enough time actually working on them. Perfection is a mortal enemy of a Scrum team. Remember, working software is what we are after. Get something built and into the customer’s hands. Instead of arguing about how a piece of functionality should work, get it in the customer’s hands and let them tell you.
Failure is the best teacher in the world. One of the things I encourage teams to do is experiment and fail if necessary. I just want it to happen quickly. A team failing over and over repeatedly isn’t healthy and doesn’t deliver value to customers. Fail quickly, learn from it, inspect and adapt, and move on. A team that experiments often and learns from their failures is well on the way to being a high-performing team. A team should experiment so that they can learn what can and cannot be done…
There is nothing like experimentation to help the team understand its capabilities.