Karmængine

Story points.

We recently made the switch to using the story point system and the most difficult thing to explain to the developer was the point of the whole thing. They were used to estimating tasks in terms of hours – a system which was never accurate and lead to utter disarray in terms of unfinished, half-finished, and poorly-finished tasks.

What goes through a developer’s mind when he tries to estimate how many hours a task will take? This:

1. How many stored procedures will I need to write? How long does it take me to write one?
2. How long to create the new page for it?
3. How long to implement data filters and sorting?
4. How much time do I need to make new tables?
5. How much time for putting it all together?

And, in the end, they’d come up with some relatively random number like 13 hours or 8 hours. “What about testing?” I’d say.

“Oh and two or three hours for testing.” They all claimed.

Bill and Bob would estimate 13 hours for the task. Alice and Alicia would estimate 8. Fred would say 20.

And you know what we’d do? We’d take an average and say that’s how much work the ticket needed. It’s shameful, but that’s what we’d do. And would have continued to do, if we hadn’t woken up one day and said “this just isn’t working.”

Incoming – story points.

We understood eventually that this was some way of comparing scope of tasks, and not an actual measurement of anything. We understood that by understanding the scope in this way we could get a ‘feeling’ about how much work could be completed. We didn’t understand why Fibonacci sequence is used, nor what we could use as a medium-scope task to compare others too. But, we gave it a try.

First, to help developers understand what story points were, the S.M. ran an exercise, where animals in a zoo had to be assigned story points. The exercise broke down under relentless questioning about small details, but the general concept was understood.

Now we’re using story points to estimate stories for addition to the sprint backlog. This is what goes through the developer’s mind now:

1. Is it smaller or larger than the 8-point task we all agreed on?
2. How much larger is it? Is it less than twice the size?
3. How many of the 2-point tasks could I complete in the same amount of time it would take me to complete this task?
4. Where’s my beer?

You can clearly see that the process requires less thought, and more ‘feeling’.

One of the ways to keep a developer happy is to remove his need to think independently, and story points take one more step towards achieving this.

So. Recently we’ve tried to make some changes to the way in which our team implements scrum. They came out as a result of a) me learning from the yahoo group and reading plenty of documentation on scrum, and primarily due to b) the scrum master getting certified by attending some CSM training.

We were managing quite well with our interpretation of Scrum, but as it turns out, if we weren’t following all the principals, we weren’t doing Scrum.

Here’s what we changed, and why:

1. Retrospectives. They had essentially halted for the last few sprints, and in any case were not conducted correctly. In the past, we would gather around on Friday, feeling either angry with the P.O. (me) because developers were working into the AM to finish the sprint, or, developers would turn up full of jokes, laziness, and pats-on-backs for getting all the work done on time.

We would sit and chat. The SM tried to instill a sense of order into the meeting, he would ask specific questions and take notes. But in the end, it was really just a relaxing little unwind session and we didn’t get a lot out of it. It did give the developers a chance to throttle the P.O., however, and they did so, shouting abuse about changing requirements and unplanned tasks being added to the sprint.

Two things were wrong with this scenario. Firslty, it is the team itself who should be committing to delivering a certain bunch of stories, not the P.O. ‘telling’ the team what to do. A BIG difference.

Secondly, there’s a purpose to these meetings, and it’s not just to discuss where to go for beer after work.

So, we’ve prepared ourselves for proper retrospective meetings, following guidelines generally accepted by the Scrum world, and expect a result from the meeting. We’ve also altered the mindset of the team to put them in the driving seat, in terms of selecting how much work can be achieved during the sprint.

As for unplanned tasks – well, there are no unplanned tasks. They should be discussed if neccessary and something should be kicked out of sprint if required. The team should be deciding this, based on the P.O. providing updated information of priority.

2. Empowering the developer during preparation meetings. The main point here is – the developers, together with the tester, enter into a kind of ‘contract’ with the P.O., to declare which stories will be delivered at the end of the sprint. This is the way it should work. We were doing it the other way, with the P.O. forcing the developers to commit to a number of tasks, and it should be said, it was usually a long list of tasks.

3. Estimating using story points. Story points – what are they? Why do we need them? The developers were eager to try something new but had a difficult time wrapping their heads around the idea of not estimating in terms of hours but in terms of story points. I used to calculate the amount of hours the team can work during the sprint, get the team to estimate the hours to complete each task, and then say ‘right, this is how much work you’ll get done’, and the sprint backlog was born.

Now, I am just creating stories with user test cases in the backlog and giving them importance factors. The Team is estimating story points based on average stories, and then giving an overall, but confident ‘feel’ (after a lot of technical discussion) about which stories can be in a shippable state by the end of the sprint. Then the stories are added.

4. Adding an ‘Is done when’ field to Trac. We use Trac, or, since new changes were implemented, Agilo, which is built on Trac. The only real acceptance tests we used to have is a ‘How to demo’ field, which would give instruction on how the work done in the ticket can be shown to other people. This was not right at all. Development without testing is like tossing seeds off a cliff and hoping your grandkids will have a fruit tree. No testing = no result.

I’ve added the ‘Is done when’ concept which I’m sure some of you probably use. It’s an english language description of acceptance tests for example, a value of this field could be “An adminstrator can log in, navigate to the accounts page, select a user account, and delete it by clicking on the ‘delete account’ button.” So far this field has had a big impact, as the introduction of any user-level test descriptions should.

5. Visualizing the sprint with a pinboard. We used to be entirely Trac based, meaning developers had to log in, and swim around in Trac to understand clearly what was going on during the sprint. Stand-up meetings didn’t help.

To combat this I have introduced a pinboard into the meeting room, where stories and tasks are pinned on, and moved between statuses before ending up in the ‘closed’ column. This lets the developers see very quickly how much work is left, how much needs to be tested, and generally how on-target the sprint is.

I’ve also put a ‘bug board’ up, which should be empty but never is. Here, developers see bugs which I want fixed immediately. They can discuss them after the stand-up meeting, and come back to me if they think they won’t manage to complete them as well as the sprint stories.

6. Devoted time specifically for bug fixing. We have also given developers a day each to spend on fixing bugs. Roughly thirty hours for the sprint. By setting aside this time, I hope that broken tickets and new bugs will not survive in the backlog long.

With all these changes I feel we’re more ‘Scrumlike’ and I’m hoping this means a better product delivery.

Here’s an extract from an email I sent to my Scrum Master.

Now, I may be wrong on some points, so please feel free to comment and point out anything you feel I’ve missed or that I’m incorrect about.

Here’s my view on how scrum should work:

1. P.O. creates stories – with story points allocated. Stories contain a field like ‘Is done when’ to place conditions on when the story can be closed (This is used for user-testing). Business-level. Stories should come from a release plan, and should have any requirements attached.
2. S.M + team divide stories into tasks, with full descriptions on work to be completed. S.M. helps the team translate between business-level descriptions and developer-level descriptions of actual work needed to be done.
3. S.M. + team discusses tasks, and estimates amount of hours for each task. Team also reports (in the ticket) expected new automated tests which will be written after the work on the ticket is completed.
4. P.O. + S.M. + team select and agree on a number of stories and commit to finishing them during the sprint. Sprint backlog is born.
5. During the sprint, requirements can be introduced or changed, which alter the scope of the tasks. This is an Agile fundamental, and cannot be prevented. The change of scope can arise when the developer looks more deeply at the task, or when external requirements change. It’s not a cause for panic!
6. During the daily stand-up meeting, developers have the chance to explain the change in scope to the team, who agree that the task can be completed, or agree that it cannot, and offer their assistance if needed (a team is a team, not just a bunch of individuals).
7. If the new scope is too much to handle, the story is either stopped, the original requirements are completed, or the story is moved out of the sprint and something is moved in (the P.O. makes this decision).

Things to remember:

• There’s one person who is going to be killed for problems with product delivery. Me.
• The Scrum Master is responsible for making sure the sprint backlog gets completed.
• The Product Owner is responsible for making sure the completed work gets delivered.
• There’s no such thing as a failed sprint. (I got a surprisingly negative reply in a scrum discussion when I talked about ‘failed’ sprints.)
• The Product Owner always has the power to meddle with the sprint and the product backlogs. The Scrum Master and team do not.
• The Product Owner and the Scrum Master are part of the team. They are just roles.

During the sprint:

• The Product Owner is gathering requirements for the next batch of stories in the product backlog.
• The Product Owner is communicating with stakeholders, and users, and getting feedback on the release plan.
• The Scrum Master is massaging the team, developing, and keeping the sprint on schedule.
• The Scrum Master is reporting problems and difficulties to the Product Owner.
• The Team is taking tickets, developing them, and writing automated tests.
• The Testers (also part of the team)

The reason I’ve sent this email is because I felt we’re not implementing Scrum correctly, and need to make some changes. Of course every company will mould scrum somewhat to fit their world, but I still think that from time to time, it’s quite useful to step back and re-evaluate. Particularly in the first year during which this process is implemented.

I did the Google Analytics IQ test (doesn’t have anything to do with intelligence quotients) yesterday and got four questions wrong (out of seventy). It’s a good result by anyone’s standards, but I feel a little hard done by.

It’s not possible to find out which questions were answered incorrectly, and that’s a bit frustrating. I think I may have got a couple of the multiple-choice questions wrong, but I’d really like to know which ones, so I can fix my brain.

Additionally, where is my super-awesome certificate which that other person got?

In all, the answers were quite easy and straight-forward, so don’t be worried if you have not taken the test and wish to do so. The only issues I had was with the language they used, which in many cases was not clear and used quite poor grammar (typical of Google).

The real quality of the test came through at the end, when a gigantic message was displayed on the screen:

“You may now close your browser. You can close your browser by clicking on the ‘x’ in the upper right of the window.”

The test costs $50 (I had a voucher which meant it was free), so perhaps this is some ’smart’ Google employee’s way of making a quick buck from vain Analytics users.

A couple of days ago I tuned into a free public webinar from Danube. I have to say, it was certainly better than average.

The session was called ‘The Product Owner’, and gave quite a neat little description of the various tasks, responsibilities, and expectations of a product owner in a scrum environment. The speaker, whose name I have not recorded anywhere (apologies), had an excellent tone and a great level of understanding, which came across to the audience.

I’m still waiting for the slideshow to be delivered, and they did try to record the webinar but I believe that it will have failed, due to a mid-presentation drop with the software.

I will attend some other webinars from Danube ofter the next months. I have a lot to learn about Scrum.

The folowing page shows the Danube Scrum webinars.

Something else I need to write about. Developers who get worse over the years. How do you handle them?

Firstly I should define what I mean by ‘worse’. Well, essentially:

• Quality of code decreases
• Ability to estimate tasks decreases
• Attention to detail decreases
• Time distracted increases
• Work done fails testing more frequently
• Contribution during discussions decreases

I suppose the first step in handling this is to sit down with the developer, a senior developer, and a director and have a good old-fashioned discussion on these points. But this is not going to do much to solve the problems, it’s just going to result in the developer either bawling their eyes out, or agreeing firmly to try and improve matters.

So, more drastic action has to be taken.

Addressing a lack of code quality

A sit-down review with a high quality coder can help. Mistakes and vicious habits can be pointed out, as well as correct principals and other methods. This should be a personal tutoring session and take place every week for a couple of hours. Yes, this kicks eight hours out of our two-week sprint, but I consider that that’s peanuts compared to the damage being done. It’s only the start, though!

Helping with task estimation

Estimating tasks is supposed to be a personal thing – the developers should visualize the process of developing the solution, of testing, of documenting and preparation. They should total the hours they’re likely to spend on these aspects and that should be their estimation. But if the developer has trouble visualizing, or breaking a task into ‘actual things to do’, their estimate will be rubbish.

To help the developer turn the task into actual things to do, it is a matter of simply extending the discussion of the task (prior to estimation) to include or share opinions from others on how they would approach it.

If the developer still doesn’t understand enough about the process to be able to give an estimate in hours, then it’s a problem. It’s a bogus developer who should be asked to re-evaluate his employment in the company. They may require extensive training, but in the case I’m talking about, where the developer has steadily declined, it may be time to put his experience elsewhere, rather on the frontline.

What to do when attention to detail decreases

Details are important, especially in software development – the world in which many finicky users stalk around with magnifying glasses. And, I personally find that when a developer makes the effort and pays attention to small things, that he is giving himself a little golden place in my heart. Obversely, when the developer ‘doesn’t give a hoot’, no matter how good they are, I get a little bit clenchy in the fist region when I see him.

Attention to detail can be increased by embarrassing the developer. Aye, it’s true. Point out his mistakes (even though they may not be technically mistakes) during stand up meetings. Laugh about them, make jokes. Be light-hearted about it, not stern. He will laugh too but watch his cheeks go red. If this continues to happen he will knuckle-down, out of the basic human need to ‘fit in’.

Another good way to make a mockery of a developer is to not single him out. Make a joke to the team that some silly person -did-whatever- and how funny and troublesome it is. If he immediately owns up to being the cause, it is something very respectable.

Removing distractions

I am always of the school of people who don’t want to restrict workers at all in the office. Introducing ‘no browsing’ or ‘no music’ policies is insane, in my opinion. The real way to remove distractions is to make the developer understand that while he’s not working, he is overloading himself in the future, and, since scrum is all about the team, he is increasing pressure on the team.

An interesting way to do this is to speak with another developer, someone who you trust and who you’re friendly with. Tell him or her that you are going to make an example out of them after the stand-up meeting, but only as an example to the other developer. Then, after the stand-up meeting, question your friend about his forum chatting or flickr browsing during working hours. Then directly ask the team how much pressure they’re feeling right now, and if they really have time to waste on non-productive activities. If they all agree that they do have spare time, that’s your fault. It might be a chance to introduce a brainstorming or knowledge-sharing session for them. That would be better than seeing them mucking about on youtube all day.

I also hate checking up on people. Procedures can’t be measured, only results can. But checking up sometimes help. It helps sometimes to just go and look at the developer’s screen. Don’t say anything, just look. They will feel uncomfortable, but since you’re not really putting any pressure on them to ‘get back to work’, they will get a splash of guilt, rather than anger. Pat them on the shoulder when you walk away, too. This is a friendly gesture which means ‘you’re part of the team, I like you’. It is a little condescending, but I feel it’s the right approach.

Reducing test failure

Again, this is where humility comes into play. It’s usually like this: the developer works on his task, tests it on his local machine, commits his changes, and then doesn’t test on the development environment, or does a very limited check to see if the thing didn’t break after his commit. Then he goes to make coffee or unwind his brain from the task he’s finished.

Then someone tests his task and boom. Test failed.

The developer often takes an hour or more to be informed of his failure, then some time to begin working on it again, then time to find and fix the problem, and so on and so on, damaging the team’s performance. Test failed tickets are like a stab wound to the team. They can be fatal.

So – how to make sure the developer fully tests his own work before and after committing? Humility, yes. Embarrass him again. Count up the number of test failed tickets during the sprint and make the developer with most wear some silly t-shirt during the next sprint planning session. Be creative, but not cruel. Make him feel like the other developers are laughing at him. There’s only one direction he can take to resolving it – and that is to ensure he doesn’t have any test-failed tickets in future.

Increasing the developer’s contribution during discussions

There’s not a lot that can be done about this one, except directly asking during discussions for the developer’s opinion. Try to get him involved in the same way you’d try to get anyone involved in a conversation. Ask questions, talk about the things they worked on, and so on.

If someone starts falling asleep during the planning session for example, depending on how horribly mean you are, a sudden clap is quite entertaining for everyone else, and will wake them up.

It also helps a developer feel like a sturdy cog in the wheel if you praise them. And, when he feels like a contributing member, he will act as one.

In the end, it’s essential to remove the ‘dead wood’ from the team’s little bridge, and replace it either by employing someone different, or solving the problems causing the wood to rot. If you don’t, the whole thing can collapse.

We are using Trac by Edgewall Software to handle our backlog. It was originally some sort of ticketing help system, but is now one of the most widely used track management softwares.

It is a very powerful tool, and that becomes obvious after a brief play around with it.

But the product backlog we have is growing, as more and more tasks, defects, and stories are being created (by me). It has reached the stage where it is so long it would take our team a year to develop it all. But, at the growth rate I’m seeing, it would be futile to even try.

What can be done?

Well, in Trac, there’s not much functionality to split the backlog, except by component but again, this is fiddly and not what I’m looking for. I would like a way to divide the backlog into blocks of work either by yearly quarter, or importance ranges.

The only solution I have considered so far is to create a series of reports, and keep my head mostly swimming around in the ‘current’ backlog block. But does this make sense? I suspect it is more a way of mentally handling the stories rather than actually dividing them up, which could result in other people viewing the backlog to become confused.

Well, this is a blog, and these were my thoughts. Thanks for reading.

So, I have been thinking. Scrum is an excellent methodology, without doubt. It’s perhaps not suitable for all software development projects, but I reckon that a majority would benefit from adopting scrum.

Yet scrum has weaknesses.

I can talk about what I have perceived from being involved in Scrum for eleven months as a product owner. I am sure there’s more than one ‘opponent’ of this development method, but I am certainly not of that ilk, nor do I wish to be. I just want to share my experiences.

Firstly, scrum pays entirely no attention to product maintenance and technical support. If you have a small company, with only a handful of developers working on a new release of a product, there’s nobody to maintain the old versions while a sprint is in progress.

The obvious workaround is to reduce the number of developers involved in the sprint, and stick them on maintenance and support handling. Aha- but for a small team pushed to make a new release, this is a disaster. Firstly, a reduced team equals a reduced output, an extended release date, and, let’s face it, less revenue.

Secondly, reducing the team reduces the skill of the team. With less knowledge available to developers, the code quality will suffer tremendously.

With less knowledge, there’s also less knowledge-sharing. If four men can’t change a light-bulb, but five can, then it’s a single man which makes the difference. The same with scrum. Remove a man from the team and the rest of the team will struggle.

Possibly, the team can remain the same size, but with a reduced velocity. Personally, I find that reducing velocity has some kind of negative mental effect on the developer. Reduced velocity translates to – more tasks. More variation in tasks in turn translates into less ability to cope with the tasks. Why? Because it’s difficult for a programmer to switch from task to task. Not only does it take time, but it also requires changing gears in the brain and doing this often leads to increased stress, and lower performance.

A classic case: Artyom (used his real name) used to be a part of my team for the new product release. Then, due to lack of available skill in the maintenance of another product, he was moved to that. That product is developed and supported in an entirely different country. Artyom faced a constant battle with himself to find time to do actual work – he was constantly bombarded on Skype by users and other developers. He would start a task, halt due to a Skype interruption, reset his brain and work on the emergency task thrown at him, receive yet another task in a similar fashion, spend hours explaining parts of the system to other developers via chat, and in the end, he was one very unhappy and underachieving developer.

Artyom said to me that it was not the interruptions affecting him, nor even the explaining which he was doing every day, it was the changing between tasks, which sometimes took him half an hour of saving, deploying, documenting, downloading, merging, opening, understanding, and reading code to understand where to begin, which created the stress and anger.

The same effect can be achieved by reducing sprint velocity. Other, non-sprint tasks will leak in, that’s one of the points of reducing velocity. When the tasks do leak in, there’s a long process required to get the developer to actually start working on it. Then the same process to continue on the previous task. This means that hours can be lost each day, not due to actual development, but due to.. overhead.

Now, the second (or first?) major problem I have found with scrum comes from task planning.

Different teams plan the sprints in different ways, but here’s how we do it:

1. Stories are explained to developers.
2. Developers consider, ponder, think, and divide the story into real tasks.
3. Real tasks are discussed, understanding is reached, and the tasks are estimated, one-by-one.
4. Estimating involves each developer holding up a card to display the number of hours they think the task will take to develop, test, and document.
5. If the differences between estimates are not too great, I take an average and assign this amount of hours to the task.

So, what happens when Mr Estimated Thirteen Hours ends up on a task with eight hours planned? Well, he struggles, he overspends his time, and essentially, spends thirteen hours on it. Well, that’s five hours lost from the sprint backlog. But, that’s the point, it’s not lost, it’s still in there, still estimated to some task, and someone has to pick up the slack.

Not only does Mr Estimated Thirteen Hours end up blowing his workload on red hours (hours spent on tasks outside planned hours), but he pushes to work faster, and his code becomes messy, his tests fail, and he doesn’t care because he has another task, failed tasks, and testing to juggle.

Before I continue I want to quickly point out one more flaw with the way we’re running scrum. Sometimes there’s one or two team members who simply cannot estimate, either due to mental deficiency, or due to lack of understanding of the task. As product owner, I can’t pick up on this. I don’t know if the developer truly knows how to write the appropriate code. If he says he understands what needs to be done, then I have to trust him. The only thing I can do is watch his eyes during estimation. He will be trying to see other people’s estimations before selecting his own.

Estimating.

Yes, estimating is one of the main problems we’re having. We strictly plan the sprint based on the developer’s estimates. With a small team, this can be a fatal mistake. We’ve had several failed sprints which have failed because the team was not large enough to provide enough intelligent estimations.

Essentially the entire release date depends on the developer estimations. If they can’t get it right, you’re boned.

Back to Mr Estimated Thirteen Hours.

He has 56 hours of work to do during the sprint. But he always, always spends 30% more time on his tasks.

He works 56 hours on only 40 hours of sprint tasks. That means at the end of the sprint, assuming other developers stick perfectly to the plan, there’s 16 hours of unfinished work. Scrum has no real way to manage this. And neither do we. We sit scratching our heads in the retrospective, wondering what went wrong.

The only solution: lower the velocity for this developer by 30%.

Now we have a mixed-velocity team. This is against the scrum guidelines. But it is the only solution I can see.

In conclusion, scrum is probably still evolving, you can learn a lot from the first year of it’s implementation at your company, and you have to be prepared to smooth-out the rules a bit, if you want this much-kneaded methodology to fit in your pie tin.

Announced for general release on the 3rd of March, 2009, the GA IQ test is said to be an essential and compulsory test for all Google Analytics Authorized Consultants. At least two members of each GAAC company must sit and pass the examination, with failure meaning review of the GAAC licence.

But wait – it seems that someone has passed it already, in December.

Google Analytics Individual Qualification (GAIQ)

Congrats to you, Samantha A Bedford. It seems like this examination was actually first offered in November, and the big news we’re hearing about now is that it’s going to simply be made compulsory. It must be my own fault for never hearing anything about this before.

Well, there’s not much information available about it so far, but I’ll be taking this test during the week and will provide a bit of an insight. I assume it will be much simpler than the GAAC entrance examination. Eva Woo has even stated this.

In addition to her statement, Ms Woo said that each GAAC will receive two free tokens to sit the exam. At our company we’re going to push for four people to sit it, and I assume the cost for the other two examinees will be minimal.

There’s just been quite a nice release from Google about the Website Optimizer.

There’s a link to the document in PDF format on the right.

A brief look at the contents:

Forward
Prerequisites
Future Compatibility
Updates and Revisions
How Experiments Work
A/B Experiments
Detailed Explanation of MVT Experiments
The Conversion Page
Setting Up Experiments
Background
Standard Experiments
Non-Standard Experiments (Testing Static Content)
Background
Setting up Multivariate Tests
Experiments with Dynamic Content
Background
Option 1 – Use a MVT experiment and custom JavaScript
Option 2 – Use an A/B experiment.
Advanced Stuff
Other Advanced Stuff
Segmenting traffic