This post closely relates to one of the questions that I have about scrum (see Q1 below). I’ll post all 3 questions here, if anyone knows the answers, please let me know.

Thank you for your help!!

BR,
Jozsef

I am a programmer working at a company that uses scrum. I have worked here for 10 months now but I still do not understand some of the rules of scrum. I wonder if anyone here could answer my questions.

Q1: During every sprint we are supposed to deliver a fully implemented and QA-d features. In theory it means that during the last 3 days of a sprint a developer cannot work because his work would not be tested (we have a large and complex app, testing every feature takes lots of time). Also, during the beginning of a sprint in theory QA does not do anything, before the first new feature is implemented since everything was perfect at the end of the previous sprint. Of course in practice things happen differently, but this is my understanding of what we try to achieve. What is the resolution? Is it a good approach to say that QAing a feature should be done in the next sprint, so no feature should be planned for 1 sprint?

Q2: Our team is organized around a feature, not around technology, and we have a several layers application built on completely different technologies. Therefore in our team we have an SQL expert, some ASP.NET programmers, some C++ guys, a driver developer and some qa people (we have 11 members). We also have external dependencies, because we implement an add-on into a platform, so of course we depend on everything in the platform. Now when it comes to estimates, you can give 1 estimate (story point) to each PBI. But since we take on work based on priorities, it can happen that from 70 story points, which is our average velocity, 55 would have to be be implemented by the single SQL guy and e.g. the C++ guys do not do anything. In this situation, is there a problem with how the teams are organized, or should the PBIs be separated into “horizontal slices”? Or where is the mistake?

Q3: What is the usual way to manage team dependencies? As I have said, we are developing an add-on into a large platform. Is it something usual that every team changes code until the last minute and then there is a hardening sprint and that’s it for testing? Or is it usual that we turn to dependencies/gantt charts: PBIxxx has to be implemented before PBIyyy can be picked up. In this case of course PBIxxx and PBIyyy are not vertical slices.

I consider this one of the many symptoms of mini-waterfall. I guess kayaking over a 25-foot waterfall every month is better than doing Niagara Falls in a barrel every 18 months, but I agree that it’s not what I’d call Agile.

A related symptom that makes me crazy is having a “stabilization” period during the iteration. My solution: stop making things unstable all the time, and you won’t need that.