I often talk with teams who claim that they’re running Scrum on their software development projects, or, at least they believe they are.
“We’re applying all the Scrum ceremonies, fixed duration Sprints, Sprint Planning, Daily Stand-up, Sprint reviews, and Retrospectives”.
“The team is using Burndown Charts to track the performance.”
“The only issue is that we didn’t see big improvements after the team started using Scrum.”
I was quite interested in why Scrum wasn’t helping in their projects, so I tried to dig into the details. I was curious how their teams run the development activities inside one Sprint.
“Well, the first thing we do before we start a Sprint is to have the team break the User Stories down into tasks. Based on the technical architecture, we’ll have three levels of development activities – design, coding and testing.”
“We use a 3-week timebox for each Sprint, so usually in the first couple days the team will work together to get the ‘JIT design’ done; then the team spends about 7 – 8 days to complete the coding part; at the last week we’ll involve the testers to test the results while at the same time the developers fix any bugs the testing identifies.”
I was a bit surprised since it sounds so much like a traditional waterfall approach even if it was happening inside one Sprint. I tried to understand the relationship between their tasks and User Stories. To my great surprise I was told:
“There is no direct relationship between User Stories and tasks, we mix all the feature-related User Stories up and have the team focus on the tasks – anyway we need to get them done by the end of the sprint, so the entire team will work step-by-step to get the feature done.”
Smells bad to me. Probably this is really the reason their “Scrum” doesn’t help – they are just applying the term Scrum to a time-boxed small waterfall. Some of the reasons I believe this doesn’t work include:
- Not working according to the User Stories indicates that they’re not delivering small pieces of potentially shippable products – this doesn’t align with the Agile spirit of “working software”.
- Having a traditional step-by-step approach to work on design, coding and testing results in the team not having a clear definition of done for each User Story – late testing is a Scrum anti-pattern.
- The team loses the opportunity to frequently and repeatedly inspect and adapt; a practice which helps assure all the work will be done by the end of each Sprint. Not doing this adds more possibility of a last minute surprise.
In a real Scrum environment, the Scrum Team should always be focused on a list of prioritized User Stories. The User Stories should be a simple and unique base of work for everybody. The team should be focused on User Stories — user valued features. This is the first challenge the team will face if they don’t want to run Scrum-waterfall. It’s not easy to break epic User Stories down into implementable User Stories especially if the team doesn’t want to break it down into the technical layers, the practice they are familiar and comfortable with. I like the approach what my team was using: for one big epic User Story that focuses more on the business value, they try to decompose it to several independent User Stories according to the user interaction. Sometimes even a series of page controls would make up one User Story, if the end-user could complete a meaningful interaction with the system. And on the back of the story card, the team writes the functional tests cases down as the definition of done. This helps the team have a list of simple but clear User Stories that align 100% with the business value and at the same time are testable.
This is the foundation of how the team executes development in the Sprint. Different from the teams I was talking with, I believe the team should not mix all the User Stories up and then do the task break down according to the technical architecture. The team should get the User Stories really done, one by one – complete JIT design, development (which should be driven by tests), and the final testing for one single User story, and then start another one.
Sometimes if the team has the capacity and the User Stories are really granular, I think it’s also good for the team to start a couple of User Stories in parallel – but for each User Story it’s still going to be a standalone development cycle. You cannot mix them up. That is the real value Scrum provides – always focus on the highest priority business value, deliver small pieces of potentially shippable products iteratively, and be able to inspect and adapt frequently and repeatly.
