Oh man, the topic of accurate estimations in SCRUM.
This is probably one of the most common battles between business owners and technology.
I’d like to point out one thing: the estimates are never accurate.
But how do you estimate? Story points? Hours? Both?
It always seems like whenever you work with a new project a SCRUM approach (especially when it comes to estimations) is handled slightly differently. Some teams value estimations and watch the burn-down chart daily. Some just slap on a number and hope for the best.
I’m going to say that based on my personal experience the number one issue with poor estimations is extremely poorly written user stories.
Without much delay I’d like to talk about issues that can help improve many SCRUM implementations, and even if it doesn’t work for your team… maybe an idea will be born from something listed below.
Let’s take a look…
1. Lack of well defined acceptance criteria
Besides getting something done it is also important to make sure that what was done (programmed) is what was intended to be delivered and consequently accepted.
Here’s a typical example of a user story:
As a user, I can view the report of all orders and filter them by date, name, and other criteria
User should have the ability to access the report at:
– filter by date (from – to)
– filter by name
– filter by amount (from – to)
– columns should be sortable
Even if I am a developer intimately familiar with the system, I would not be able to estimate very accurately.
As a developer I would have two options:
1. Go on a hunt for missing information (let’s see below)
2. Make a bunch of assumptions (can’t spell assumption without ass)..
Let’s make a bunch of assumptions.. shall we?
The report is in the “admin” section, the user should be logged in as admin (let’s hope there’s only one tier of admin users and only that one tier should be logged in.. we don’t know)
I presume that the report should look like the other ones in the system so far, and make my best attempt at the design.
Four days later the report is loading, it looks good, the filters are working the user has to be logged in as admin. Columns are sortable. Not much to add.
Time to demo the story to the stakeholders… after some interesting conversation the story is rejected.
2. A story that requires research
Why did the above story get rejected?
Well it simply didn’t pass the acceptance criteria set by the business owners. Too bad we found out about this later.
The pagination was off… and apparently only shipping managers and super-admins should have had access…
There were a couple of other minor issues… but one of the required columns was missing (and apparently the data we need is stored in a completely arbitrary table elsewhere).
The number of reasons the story was rejected could go on forever.
The real question is how can we anticipate all these changes/addition ahead of time?
Simple answer: involve business early.
More complicated answer would be to introduce “spikes” into your sprints. This becomes a business practice not a “let’s try to have a meeting about this” type of deal.
Spikes are usually viewed as oddities and negative things. Perhaps so.
But introduction of spikes is often necessary to weed out the problems.
The idea of course is that over time you need to rely less on spikes and the user stories become better defined.
Then comes the question of accountability. If during research and analysis you don’t have an agreed upon design, a clear definition of what should be on the report and who should access it… then you’ve done your analysis poorly. And hopefully you would know so ahead of time, because a spike just like a regular user story should be estimated, demonstrated and accepted. Whether it’s a Photoshop mock-up or a working prototype it’s best to get feedback early and often. Spikes help to accomplish exactly that.
As developer it is simply best to find out where your development user story is headed before you get to coding. If the business is happy with the proposed direction, then chances are the outcome will be as desired.
Getting “on the same page” early is good and necessary.
3. We forgot about QA
Yes we did. QA is not there to break things… if developers aren’t working with QA early and often, then something is going to naturally break eventually.
I know how to develop and how to make something work. But I don’t have desire nor time to figure out all the scenarios and permutations required to potentially break something or otherwise invalidate the user story.
Going back to the point of acceptance criteria… As a developer, QA should be your first line of defense against poorly written acceptance criteria. During your pre-planning meeting, review of backlog or at the worst case at the beginning of the sprint as developer it should be a necessity to meet with QA and discuss the story at hand.
I need to know what the QA will be looking for so I can write the code in such a way that it would pass QA acceptance.
With that said, I hope that my research for the user story has been thorough enough and I can actually estimate the task much more accurately.
If I still feel that we have unanswered questions it is best to introduce a new spike or escalate the story ASAP.
Communicating problems in SCRUM is better before the beginning of the work than after.
And remember to include QA time in your estimations. If you have 4 days (approximately) to work on a task, you better not start 4 days before the end of the sprint, or the story simply won’t make it. Consider that QA needs 2 days to test and there’s a day of defect fixing. So the total estimation cannot be done just from the developer’s point of view.
Not only that, a story that might be simple to code could be much more complicated to test and that should be accounted for whether in time, resource or complexity estimations.
4. Technology needs a strong voice
But what happens if all of the above was done right, yet business owners still reject the user story.
Well, then simply put its their own fault. Yet often there isn’t anybody to defend the developer.
If business owners were involved in the process from the start, they simply have no room to say that this is “not what we wanted”.
Granted, anyone could say what they want, and that the previous designs and discussions were just a fabrication and food for thought… At which point I would seriously consider employment elsewhere.
However, that’s not really the solution.
Either during planning or acceptance someone who represents technology (without the fear of being fired) needs to point out where things went off course and how to mitigate the issue going forward. Hopefully those responsible will behave better next time and crisis will be avoided.
But in case of emergency break glass, any glass… and look for a new job.
5. Business owners are a part of the team
There should not be such a fight between business and technology departments. But there almost always is.
Somebody has to be at fault and someone has to be right.
But if you can learn something from negotiations, is that the sooner you get the other side to “work on your team” — the better. The quicker any negotiation will come to a reasonable resolution.
This should be much easier inside a company. After all you are all working on the same team, presuming that you all agree with the company’s vision and believe in the product. If not, that’s a different story.
To reiterate my earlier point, the sooner technology gets business owners into the process of development the better. If business owners do not have time, they need to designate a resources that would be responsible for being there all the way through. From idea to implementation.
Without such intertwining of business and technology it would be nearly impossible to establish clear communication and well delivered products.
6. If it feels too complicated, it probably is
If it can be tested and delivered it should be a user story.
Yes, a single function can and should be its own user story when appropriate.
Sometimes it is tempting to say that a chunk of code by itself is useless because it doesn’t do anything. Well, let me ask you again… can it be tested? Does it perform any sort of logic? Did you actually attempt do write any unit tests for it? Chances are it is not as useless as you think.
Let’s take a look at an example…
A user story might require us to create a table add a couple of methods for data processing to our model or DAO and display this data in the UI somewhere.
While this sounds like one cohesive unit it really is not.
If you take a TDD approach (as you should), you can break this up into smaller testable units.
– release script/migration to create the table
– unit test and fixture data for method one
– production code for method one
– unit test and fixture data for method two
– production code for method two
– ui design
– front-end test
That’s a lot of “testable” stuff that can come out of a single user story. And even if each one of those pieces cannot become its own user story, it can certainly be split up into at least two or three.
Even with everything above working systematically and perfectly we’ll never achieve a consistent perfect-world scenario, where there are no emergencies or otherwise re-scoped sprints. Things change and blow up and priorities shift.
As developer I need to make sure I am always aware of what I am supposed to deliver, and that I am relatively protected because I am not working on my own in the dark corner, but make my work transparent, demo-able and involve others to be aware of what is being done from the start of the process to the end.
To conclude, I’d like to address all the managers out there… If you have to ask: “What is going on with this story?”, or “Where is that story?” (other than in a daily stand-up) then you are a doing a poor job “managing”. Manager (scrum master, project manager) should be equipped with the necessary tools to answer that question. It is not developer’s job to report on the progress. Simply put if you are not aware of what’s going on with your team, then you need to seriously re-evaluate your approach to communication and your current business processes.