Story points story

For sometime there’s been debate on the use, or even the need of story points. Hmmm…. There are  multiple needs to consider:

1. Short term estimation, so as to commit for a sprint.

2. Prioritisation decisions

3. Release planning

Though controversial there may be another reason:  Productivity gauge (caution advised)

In this discussion I’m assuming you are executing projects using Scrum or some other short cycle iterative approach.

The two matters to consider are:

1. Do we need to do any estimation at all?

Well, unless you seldom have to prioritise a work packet over another, or have very large capacity you need to estimate (not exactimate) items. So for a vast majority, the answer is yes.

2. Should we switch to story point estimation?

If the current method of estimating is able to handle relatively small packets of work (enhancements/change requests)  taking into account the whole cycle from analysis to delivery (to staging) with reasonable reliability, there is no need to change to story points. However most projects don’t find themselves in such a happy state and story point estimates is a good approach. There are many reasons why story points are a superior choice (at least at the team level);

But finally the only good circumstance in which we can avoid estimating altogether is if we can always break items (or user stories) into small uniform sized pieces of work (taking just about a couple of days to complete). Then all we need to do is look at the business benefit for every story and count the number of stories. The velocity is given simply by number of stories done in an average sprint. This uniform and consistent division is not usually easily achievable.

Advertisement

Case for starting with longer sprints

At last something reasonably sensible here, from a big Indian services company regarding Scrum. I say reasonably, because the conclusions arrived at are largely correct, whereas a couple of points made in support reveal an underlying thinking which is slightly questionable. I shall proceed to answer the Q of an “ideal” sprint length before returning to take apart the article referred to above.

Most Scrum teams use two week sprints and a few even one week sprints.  In some organizations where iterations have been about 3 months, or more in length or even worse a classic waterfall (Before Scrum) teams have a real problem starting with two week sprints. Much of this is in the mind. It is common for people in such projects to feel (or even ‘know’) that nothing can be achieved in two weeks. So, there is considerable reluctance to pick a two week sprint. Now the question is what should be the length of the first few sprints?

Something of a storm in a tea cup, is how I see it; There is no doubt in my mind that a two week sprint (with suitably small units functionality as backlog items) is what the doctor ordered. However in these times of diminished authority, quite a few people seem to duck clinical instructions, let alone heed good advice. So, a logical (at least superficially) decision is made where in a much longer sprint length is chosen.  If it were of four weeks, that is still within the rules of Scrum, but not a good choice. I’ve even seen a two month sprint taken up as how to proceed with Scrum, which  really is a marvelous illustration of how NOT to do Scrum. Basically the underlying problem is once again the lack of realisation that Scrum is really a rather radical departure from the traditional waterfall way of completing projects. Not an embellishment of the old ways of working with the latest jargon, minus the real intent, which in turn simply results in Scrum-but.

So why is a long sprint three weeks or more a problem?

1) Loss of feedback (course correction opportunity): Essentially there are fewer opportunities for the PO and functional stakeholders to get to know the growing system and provide feedback.

2) difficulty of holding on to the “NO CHANGE RULE”, particularly the part where the sprint goal has to be held fixed; i.e no changes to the stories picked up by the team at time of SPM (sprint planning meeting) are to be allowed, is increasingly difficult to maintain as the length of sprint increases.

3) Effectiveness of retrospective: One of the most important environmental conditions for a good retrospective is that people should remember what happened during the sprint. The only other even more important condition is openness and assurance of safety. Most people cannot recall many (unremarkable, but important) details beyond last week. That’s a two week span. So once a sprint is longer than two weeks, we have a memory retention problem, unless the team maintains a detailed activity log. Yeah right!

4) Reduced planning effectiveness: As the time horizon increases, it becomes more difficult to plan for the entire timebox. It is substantially more difficult to plan a longer period of activity realistically than a short one. A weakness of long term planning ability exists in most software project groups.

In fact all the above means, it is imperative that teams improve their ability to plan (a major underlying factor is estimation, but that is another long story), make progress, correct and then build upon what has already been achieved.  Basically do the “inspect and adapt”. So in a way more opportunities the better. Hence a shorter cycles are better.

OBERVATIONS on the Cognizant article

(Overall I think the article is well written and has many aspects covered well)

Pl refer to table in the article.

A flawed line of thinking here is “Adaptation to uncertainty in story creation”, which talks about stories crossing sprint boundaries. This assumes that stories are going to be large. Actually they can be quite small. Short cycles can be handled if the organisation and team learn to break functionality into sufficiently small blocks (here is an interesting thought on this matter). This is a skill that needs to be developed, and time after time many people have discovered that the most complex application can be broken down into block that need a couple of people to work on it for a couple of days. So ideally for a two week sprint a team of about seven people about 8 to 15 stories (or sub-stories, if you prefer) can be picked up.

An argument made by armchair planners against short sprints is that the overheads will take up a greater percentage of time as a whole (as possibly being hinted by the above article; see 32,16,11 and 8 days). However for shorter sprint the planning, review and retrospective times will also come down;  Of course time spent arranging for these meetings may go up, since number of meeting per month will increase. However this is a matter of habit, if everyone soon gets used to weekly meetings (each meeting of shorter duration) this will actually be a negligible overhead, with a tremendous amount of learning and correcting being generated. So a shorter sprint is better than a longer sprint.  So item 1 “Ceremonial days” in the table isn’t quite right.

The other (more worrying) point made is that about procrastination;  Use of sprint burndown chart correctly will actually circumvent this! In fact very long sprints may just increase pressure on the team since there is a real possibility that team will struggle to meet sprint goals towards the end of a sprint. There is a real danger of falling into a serious waterfall mode every long sprint. Teams don’t seriously examine their way of working and change to get as far away as possible from the waterfall. In fact in this matter the article seems to lie on a resource (read people) utilization perspective and the worry that people are not going to be busy all the time, easily confusing activity for progress; which is fairly anti-Scrum in approach.

Another issue with the article is the point about “minimum number of days spent testing”! This is really puzzling.  Is less “testing” days better, or worse!?! I’ve no idea what this article considers better, let alone what the thinking behind this is. In reality it depends heavily on the context of the project, the abilities of the team members,  automation involved (rightly or wrongly)… so many ifs and buts. In fact Scrum does not even attempt to prescribe this.

So the main root point in favour of a long sprint is the comfort of the team and managers involved coming from a waterfall habit! This is really a question of willingness, understanding and realization of the people involved in the project. Not something to be sneered at, maybe a coach can help.  He/She must show sensitivity to this, and do all possible to show the team how to break down user stories into smaller blocks of functionality.

In closing…everything else points to shorter sprints. A two week sprint is strongly recommended and indeed used by many, many successful Scrum teams.

PS: The points made above may seem like a merciless slating of a deeply flawed article, but not so, the article itself makes many good points from a certain level of Scrum understanding.  I think it analyses the various factors of making the sprint length decision fairly well. Here I am simply attempting to provide a deeper understanding of how to think through this matter.

Retrospective: The driver for change.

Ensuring that the retrospective makes a real difference

This post is only partly in response to an observation made here that retrospectives were found to be generally useless. Having said that the practical tips in the above post are valuable.

I think the feeling (or even reality in some places) that retrospectives are a distraction is due to a few factors

1. The software development organisation, as a rule, doesn’t have a culture of self-improvement (neither developers nor managers)

2. Many teams struggle just to get to the sprint end date meeting the sprint goals and lose stamina by then (an important tip is covering this). Oh, yes I’ll not be in the least surprised if the cause of this is organisational pressure applied onto the development team. Similarly this pressure will lead to ineffective retrospectives.

3. Poor visibility, hence support for getting action items done (also mentioned and dissected here)

Retrospective is the driver for change generated by the team (and possibly anything that the SM points out). So after the lovely discussion how do we actually make the change? Hopefully the Scrum Master and the team have identified action items (not always easy, not always correctly done), but even so, some of them will be straightforward.

It is all a matter of perspective: Encourage all concerned to view the retrospective as a driver of change; and I think it’ll have a very different effect. At some point (ideally the beginning) of the project, or when the team is getting stuck, floundering etc., it has to be said “There are things that are not quite right around here. We need to change, bit by bit; Let’s use the retro”. Wonderbar! but how?

TIP: Suppose these action items were to be put into the Product backlog. This is an extension of suggestion here. A bit radical, eh what!?! as normally the product backlog is reserved to deliver something for the PO or external stakeholder.

caveats: Some action items need a lot of work/effort to be made and teams tend to drop these items from their to-dos, so these could go into the product backlog. Not all action items need go into the product backlog, as some can be done by the Scrum Master, some by the development manager (hopefully) and some are simple to do.

Coming back to the suggestion: What is the effect of putting retrospective items into the product-backlog? It certainly gets attention (visibility), and these items also get budgeted. More importantly a lot of careful thought based on experience WILL get acted upon. But there is something of a dilemma here, as then the PO gets to prioritize the action items! How would a PO react? What does the PO’s reaction tell us? Something of a litmus test, as to how well the whole team, SM and product owner understand the principles and imbibe the ethos of Scrum. This may often mean that the coach/Scrum Master will have some convincing/cajoling to do. However, while it may take time, eventually the team and organisation around it can see the effect of doing/ignoring retrospective action items (as there is greater visibility). Yes, it also gives the Scrum Master a great handle to encourage improvement via these action items.

WHEN NOT TO RETROSPECT: (ideally a separate post, but I’ve the first quality of a programmer)

I’ve as a coach often observed  teams which struggle to meet the sprint end deadline and led and facilitated their retrospectives. A team that takes it’s commitment seriously is at a disadvantage, as they have been working overtime for the last few days (nights!!?!). This usually means that their sprint review meeting, in such circumstances doesn’t go like a bomb, (don’t bother this link if you are from the UK/antipodes). By the time they are done with the review they are tired, somewhat dispirited and possibly uninterested. TIP: Give the team some recovery time. Don’t hurry into a retrospective under such a sepulchral atmosphere on the same day. Don’t hurry the retro to get on with the next sprint. You almost surely will be failing to learn. An ineffective hurried retro is time wasted, a longer one with sensible action points (which get acted upon) is valuable learning and a “velocity+morale” booster. If you must, hold a 30 min debrief. Especially, if the next day is a working day, people will be late, and the retrospective must be conducted well. So the main body of the retrospective should be around lunch the day  and concluded after lunch. This is to give team members time, discuss formally(during meeting) as well as informally (over lunch). In case the sprint ended on Friday evening, we can conduct the retrospective on Monday morning (with a long coffee break in between). But do make sure that at least three action items are identified and people commit to acting upon them (maybe put them into the product backlog). There must be visible progress over time, else each following retrospective would become more useless than the last (ironically, the reverse result for the retrospective itself, opposed it it’s intention for the project).

I’ve generally seen teams benefit from decently conducted retrospectives. As time passes and the retrospective action items become larger and more difficult this improvement slows down. This is where higher visibility (as suggested here) and perseverance will pay dividends. Good luck and God speed.

An extended entertaining tete a tete

I had the pleasure of meeting Jeff McKenna last weekend. I took him around the city a little bit and had lunch with him as we chatted about various things, with discussions about Scrum taking up about half of the time. He was very engaging. He started programming in the sixties as a young teenager and talked about a seven pass compiler! Blimey! Glad I didn’t have to go through that wringer. Must have been fun in someways, but surely not pure joy when an error was thrown up on the sixth pass. He was also among the vanguard of the Smalltalk community. That is why meeting him was also a privilege. Such a spectrum of experience! He has I’m sure a store of stories to narrate and observations to make, only a small portion I could listen to.

In any case, one of the points he made really well was how you can always break a seemingly big story (feature) into much smaller parts. Many people who come from a traditional background seem to struggle with the idea of taking a functionality from description to implementation in just one sprint.  They think “well, our application is complex (glossing over the fact that complex and complicated are different) and we can’t implement anything meaningful in a two week sprint”. Indulging in some levity he makes the point thus “you can break it down to a few keystrokes!” Touche! But the point is serious. You can take it from people who have seen a really wide range of computer software applications, many times more that the average Mac, that one can always, always break functionality down to a couple of days of work. Surely within a development environment this is possible. There may be other organisational barriers that mean that the implementation cannot be taken into pre-production (or whatever) within a two week timebox, but the point of Scrum is to remove as many of these barriers as possible.

More on this later .

The VOC, but who is the customer?

A recent post encouraging proactive steps to gather the VOC leaves the issue of “who is the customer?” well alone, since a generic answer would be vague, it is heavily context sensitive. Many good ideas are presented here.

An intriguing point made here is that, these are solutions to a situation “…particularly where there is little time to do any early user research”. You must consider what is underlying such a train of thought carefully.   I hear this sentiment sometimes and it is almost surely leading to building of the wrong product! So lot of activity will ensue, but progress in terms of generating ROI may is certainly not ensured! In other words it is a case of leap before you look. This is not to say what’s written in the above mentioned post is wrong, or that it is recommending ignoring user research. It just is trying to work around a poor decision.

As usual since my blog is about Scrum,  here I’ll try to relate this situation with the product owner’s role. To cut a long story short, it’s the PO’s responsibility to bring the VOC into the project. Identifying and engaging with customer(s) or potential customers and the difficult balancing act that may be needed is in the PO’s court. Again it is difficult to provide general advice that is practical but it certainly helps to make as much activity around this as visible as possible. The transparency of such interactions will mean a very significant reduction in dysfunctional behaviour. So as far as the teams are concerned the PO is the customer, albeit,  one who follows the rules of Scrum.

Strictly left footed right wing striker

Background: The Pune vodQA 2012, where I was involved, but not entirely committed(A frivolous reference to Scrum lore, about commitment, chicken and pigs) in more ways than one, was interesting instructive and illuminating! Read about it here.

Mr Chaitanya Nadkarny, a senior member of Thoughtworks consulting gave an opening talk, covering among other things which factors are going to affect the lives and careers of testers. One point he made was with regard to how testers can be generalizing specialists, or specialising generalists. It took some time for the audience (at least I did take time) to get it’s collective head around this.  Mr Nadkarny’s point here was that

One could be a performance tester (specialist), but also interested in expanding capabilities (therefore generalising) to do general functional testing, manual etc.

OR

A tester (generalist) now wants to be more skilled and focus on an area of testing, for example usability (specializing).

MAIN POST:

Since I see the world through Scrum tinted glasses, I’ve been struck by how Nadkarny has put in a nutshell the possibilities of how people develop, become more valuable and competent. Many years ago a programmer was doing most if not all activities in relation to developing systems/applications, including testing. As the field developed people became more and more specialized. Eventually in the noughties, we have extremes of specialisation. Even being a tester isn’t enough of specialisation, one is now a manual tester or an automation tester, or a performance tester. The side effect of the industry moving in this direction is that people are squeezed into ever narrower roles, even though this isn’t required and actually creates inefficiencies. Finally we have the equivalent of a striker who can only play on the right wing,  kick with his left foot, but will not head the ball into the net, even if the ball is at eye level, straight ahead and the keeper is out of position!

This attitude is so entrenched  and pervasive in some places that even managers have often fallen into the trap. People are type-cast and given no opportunity to learn new things. The Scrum team, essentially being cross-functional, would struggle to succeed if a group of super-specialists have to work together, even if they are initially willing to collaborate. Why so?

Firstly: There is little understanding of what the other person does and needs.

Secondly: Load balancing at different points in a sprint is a nightmare, as work of a given type isn’t evenly loaded throughout the duration of the sprint.

Thirdly:  Majority of work in any organisation is done by generalists, because much of the work doesn’t need a too much of specialization. How often have you visited a general practitioner vs a specialist?

Lastly and very importantly: it encourages the continuation of waterfall habits.

Time to generalize. A cross functional team would need generalizing specialists.

On the other hand, once they get there, they might then need to be specialising generalists, as well… and so it goes.

What can be done when the PO isn’t empowered?

A fairly common situation in organizations is the presence of a PO without authority. It is common for a BA to play this role, and mainly due to the mistaken belief that functional knowledge is  the only criteria for a PO. Also the term ScrumMaster suggesting an all important person in a move to Scrum, contributes to this thinking. As in many things the best course of action is to preempt this situation by educating the rest of the organization (before) the start of Sprint about the roles of SM and PO. Once the realization set in, that the SM is not responsible for the delivery on a sprint to sprint basis, and in terms of delivering the product to the customers, people outside will turn to the PO. The PO will then slowly take on a stronger and more meaningful role, suffused with responsibility.  In my experience, coaching project teams and organizations, this take some time. The first level of understanding come about in 3 to 4 sprints, but deeper understanding typically takes a release or two (maybe 3 to 6  months). What one can do to make this more visible:

1. Re-iterate that Scrum is a radically different system of running software projects.

2. Encourage interaction between team and PO, as well as PO and external customers/client.

3. Explain to all concerned that while the team is largely responsible for “building the system right” every sprint, the PO is reponsible for making available “The right system”. While the team is collectively responsible every sprint, the release to the customers is the responsibility of the PO.

4. In addition for a release the PO is ultimately responsible for delivery of the “right system right”, in other words the appropriate system which is shippable (i.e of high quality)

Sprint Review undone: Part-II

Please see previous post for the context.

Lack of prioritization (within Sprint).

The overall result (certainly from a PO view point) is nothing delivered. Many teams see this in a very different way. This reminds me of a story: Mike was looking for his shoes,  and his servant who was responsible for taking care of them was trying to find them. All the while Mike’s irritation was increasing, after some time  the servant said in a voice where consolation and triumph were nicely blended “Well here’s one shoe!”. To which Mike replied “What’s the good of one shoe, you duffer!”.

Well, what of the poor PO. What did (s)he get for the patience? Nothing!

The team has worked and actually done(on the average) about 80% of each item!

This statement demonstrates the inherent weakness of the traditional means of assessing s/w development progress.  In other words percentage done. In the Scrum world we should strive to get a story/item ‘done‘ unambiguously in accordance with a strong DoD.  But I digress somewhat….

So the vital point is that: it is better to complete 80% of the items 100% (ie ‘done‘), than do 100% of the item 80% (ie, none are done). This is possible if the priority of items/stories chosen for a sprint is   considered and acted upon. So the higher priority stories must be taken up first, and all efforts must be made to complete these, before focusing on the completion of the lower priority items. This consciously applied pretty much ensures that the PO gets at least a couple of items. Moreover they are very possibly the highest priority items! So the PO can potentially derive value out of them sooner. The SRM cannot be viewed as a disaster, an important benefit.

Sprint Review undone: Part-I

I was recently present at an attempted Sprint Review Meeting for a team I was coaching. They were struggling to get finished by the time of the meeting, and by the appointed time could not get the functionality ready. The problem was that they had picked eight items, and could not even demonstrate one item, and this was their second sprint! They had earlier done a sprint zero, with many of it’s attendant problems which are described here. Now my overall  analysis of how this situation came to pass is at two levels:

1. Poor habits carried over from the waterfall days.

2. Lack of prioritization within the sprint.

Over and above this is the matter of a somewhat diluted DoD (a separate topic in itself) which is bad news being stored for the future. This team was working with a weak DoD, which was seemingly clear to them (For some one who reads tea leaves in his spare time, this is an ominous sign)

In this post I’ll explain the  first point. Within the sprint, each story was done strictly in a waterfall manner, including hand-offs. This not withstanding all the training the team and managers were given. Which meant, that the burndown chart, while warning about bad news, actually did not quite manage to reveal the really bad news. That nothing was actually ‘done’ ( this does not mean the team did not do anything). Suddenly towards the end of the sprint 4  user stories  were 90% done, and as the old saw goes, the remaining 10% takes the other 90% of time. The other 4 items were in even lower levels of completion. However what was the actual completion is moot.  Even more importantly, trying to find out the true completion percentage is missing the point. The team at the time of the sprint review, should try to keep the done/undone as binary as brutally as possible. Try to see it, standing in the PO’s shoes.

So what is to be done? Avoid waterfall. How? Especially given that the team is already facing too much change for comfort (One reason why many teams don’t see successful sprints early on).  Assuming they haven’t changed their technical practices yet (very common for teams starting off on Scrum), the first step is to try to break-down user stories to even smaller units of functionality, whose completion should be staggered across the sprint. Another approach that can be simultaneously used is  to write acceptance tests as the stories are picked up. This means that the team can test the stories (to some extent) at a very early stage, hence testing early and (hopefully) often.  A very good idea.

The above ideas are a reason why teams aiming to succeed have to change their ways of working and learn to breakdown stories and change the approach to testing among other things.

In the next post I’ll explain the other practical step to take (if you haven’t guessed already).

Handling changes in Scrum

Srinivas is the co-author of “Essentials of Scrum practice“- a mini-book
currently in a draft stage. This is an extract from the book.

 

All s/w development projects have greater or fewer changes to be incorporated after the start of development. So how are changes handled in Scrum? and more importantly why are they handled in the manner described/recommended by Scrum?

Basically in Scrum the top few items of a product backlog (the highest priority ones) are chosen for any given sprint. The remaining items, can be modified by the product owner as he/she pleases at any time. As an aside, there has been some recent talk about the backlog not being prioritised, but ordered. I’m less than impressed by that explication.

Since Scrum is supposed to take care of changing functional/non-functional needs over time, the germane question is “How do we handle changes within a sprint/iteration?” in other words “how do we handle changes to the sprint goal?”. This is a recurring question, and the answer lies in correctly understanding the intent of Scrum.  Scrum’s intent is to provide a means, an island of stability where a complex project can be run smoothly, even though the environment around is in flux. This island of stability  is ensured by the “NO CHANGE RULE”. Which means no change in duration, goal or team for any given sprint.

See the following post for the reasoning on keeping the team fixed. Here I’ll essentially cover how and why of keeping the goal fixed.

There are two cases which cover changes to sprint goal

1. Urgent bug-fixes which may turn up at any time, hence cannot be foreseen at the time of the Sprint Planning Meeting (SPM)

2. Change requests to the selected product backlog items

These two cases are to be handled in radically different manner. For the first case the team can inspect and adapt to choose a means of dealing with bug fixes, by either keeping a percentage of available time (say 10 to 15%)  aside as contingency or by rotation having one or two team members on stand-by to handle the bug-fixes as and when they turn up. In other words this is being prepared for the unpredictable. The second case is severely discouraged and is  handled by not taking it up in the current sprint! This may seem extreme, but there is sound reasoning underlying this approach.

First and foremost, if change requests are allowed at any time within a sprint, there is no line drawn as to how much of change is allowed. Given human nature this will result in any amount of change being allowed any number of times with any sprint. What is the implication of this on the usefulness of the SPM? We are very possibly on a slippery slope by allowing a change in sprint goal, mid-sprint. Essentially, by having this rule, we are creating an island of stability.

Secondly, the reason we have sprints with items being pulled into any given sprint, is to accommodate change. This means at a project level change to functionality is handled in an orderly fashion as well as a welcoming manner.

Thirdly, and this will be difficult to stomach for some stakeholders,  a significant amount of change is due to lazy thinking early on. In other words quite a few of the change requests are a result of not thinking through what is needed. While it is recognized that the PO/customer cannot always know everything that is required in detail, up-front, what this rule does is encourage reasonably detailed analysis of the items which are at the top of the backlog. When the PO is confronted, with a situation where he/she/it (How PC am I becoming!?!) has thought of a change and has to wait till the next sprint, this is a stimulus for more careful thinking before and during the following SPMs.

The encompassing principle above is that Scrum is a system that encourages corrective behaviour from the stakeholders, while maintaning a balance between accommodating change and reducing avoidable waste due to lazy change.

Two further points:

1. Scrum does NOT need (in fact discourages)  to have the functionality described in every detail at the starting of the sprint! Then, how in the blue blazes are we supposed to keep change at bay, as clarifications are made during the sprint!?! There is another simple rule in play “If in doubt, it is the team that decides whether it is a change or clarification”. In case of clarification the team simply implements, in case of change, it gets put away for following sprints.

2. What if there is an utterly, unavoidably, compellingly, the-sky-is-falling-on-our-collective-heads, URGENT change of sprint goal, in the middle of the sprint!?! Either a change to an item picked in the current sprint, or an altogether new item added.

Well, indeed if it is THAT important, follow Scrum by the book!

i. Terminate the sprint

ii. Inform all stakeholders

iii. Immediately start a new SPM for a sprint, of what-ever length, that makes sense for the explosive circumstance. Does one need to do a full SPM (of 4 hrs?), not really. Exceptional circumstances can mean that just the new/changed item is to be dealt with in the planning.

Any loss of time/money/delay due to this decision is made in full knowledge by the PO.

Again note, that this is a highly disruptive, but necessary change, and is widely visible. Not to be undertaken lightly. After all if there is a serious earthquake, the sprint goal will change.