Day 2 was a great one for me and the material today helped quite a bit with some stuff I was struggling with. Of course I now realize I was struggling with some of this stuff because we weren’t really applying the Scrum principals properly.
So let’s recap what I originally thought, plus what I learned in day 1 and add-in stuff I learned today. There’s 1 day to go in the course so I plan on writing more concise and organized posts, but I really want to dump my brain first.
You cannot introduce new scope into the sprint. ever.
Well, I suppose I shouldn’t say never. Shit happens right? It is a strong guideline that after sprint planning and before the sprint review, new backlog items should not be introduced. It’s up to the Team’s discretion to allow this but the Stakeholder and/or product owners must agree to take something out. You should avoid this and it should not happen frequently. If it does, your sprints are too long.
Your velocity should level off
Seems I missed a biggie here. There is ‘planning velocity’ and ‘commitment velocity’ Big difference. You can’t predict the future obviously, but you can get better at estimating. When your ‘commitment velocity’ levels off, the team has success. Both types are really simple to measure and Scrum accounts for that.
The Team should commit to the work
No change in opinion, my assumption was right.
The Team must agree on what ‘done’ means
My assumption was right, but I learned a bunch of ways to deal with this that will help me apply it. There’s different criteria for a task, backlog item and sprint/release. IE: a sprint being ‘done’ means all the backlog items were completed and a demo was held to showcase the functionality completed whereas a task is done when the tests are written and pass or a code review is done etc. It is critical to agree on this however and there is no repeatable forumla that works everytime. Discuss, agree and get to work.
The Team should be accountable
The jury is still out, we ran long today and didn’t get to it.
Communicate and be reasonable
No change here. TRUST is hammered home with scrum. The Team will fail. It is important to TRUST them to fail so they can learn and self-organize better. Scrum has a framework and very well defined rules, but there’s no substitute for communication and reason.
My Big Problem List
User Stories: talked a bit about it, but that’s covered in day 3. A couple key points is that the backlog items (in the form of user stories) are requirements. A user story or backlog item is a vehicle that should lead to a discussion. It is by no means the be-all-end-all of the requirement. I hope we cover this as it’s an optional module on day 3. Another key was that backlog items are estimated whenever the backlog changes, NOT at the beginning of the sprint. Basically you keep a revolving door going so there is no downtime and long planning sessions to estimate stories.
Putting time against tasks: I am happy to report I was completely wrong and now I get it. Meeting goals matter, time doesn’t. There are formulas and metrics (burndowns) and those are all you need. There are some guidelines like 1 person can do 1 task per day. Math will tell you basically how much work can get done. Often time tracking is only used if you bill on time/materials or for bean counters but it became very clear that Scrum has no mechanism for handling time tracking at all or putting time against any backlog item/task.
Priorities and dependencies: similar to what I learned yesterday, but with some additions. Analysis, design, construction and testing happen throughout the sprint, almost chaotically but NOT in a waterfall fashion. IE: if QA is part of the team they don’t wait to test all the backlog items until the end of the sprint. The Team basically decides what their block are and, with help from the Scrum master, they break those blocks. IE: I can’t start this until Joe finishes that, BUT I CAN start the other thing. It’s hard to be idle.
Dealing with Interruptions: When you’re talking about scope creep, it’s simple. Something in, something out and the Team decides whether or not to accept the change. When it’s the unknown due to customer support that may or may not happen and the unknown of the effort to resolve the potential support problem, there is hope. This is a very long discussion, I can’t get into it here but I did learn a couple of ways to handle it.
Team Adoption: we didn’t get into the Team module, but we did talk about approaches for implementing Scrum from the ground up. The key was quick wins by demo’ing shippable software. Once management sees immediate impact, they are potentially more open to it. At the end of the day the best approach came down to “it depends…” which is common to Scrum. Only you know your environment and what works for one might now work for the rest.
Why is the SM doing the sprint planning? Same as yesterday but there was some added insight that helped me understand just how wrong my whole approach was for the sprint structure, planning and estimating. Well, not just MY approach, but the approach I inherited (No offense intended to those who know what I’m talking about but man, we suck ass at this and it’s soooo anti-Scrum it hurts!)
Day 2 retrospective: Day 1 and 2 gave me a lot of great tools for being a much better Scrum Master. I knew quite a bit of these Scrum principles by reading, but there is a huge difference between being Blog smart and actually being TRAINED on what is right. By ‘right’ I mean, ‘right according to what Scrum is and the rules of Scrum’. Scrum is easy. Implementing Scrum is hard and a LOT harder than most people think.
Day 3 we’ll talk about teams since it was bumped today (damn that points exercise!) and get deep into the definition and responsibilities of the Scrum Master. The day will close off with a case study, optional modules (crosses fingers for user stories!) and Q&A.