Daily stand-ups and the 15 minute challenge

The daily stand-up or daily Scrum is an essential feature of Scrum. It requires that everyone be present in person, or call in. It is a time boxed event which means it has a time limit and cannot exceed 15 minutes!

There are three essential questions every team member answers in the stand-up – what you did yesterday, what you plan to do today, and if you have any barriers or obstacles. The meeting takes place at the same time and same place every day to make it easy and ‘automatic’. Some teams do this at the beginning of the day, so that they have a roadmap ready for the rest of the day. Some teams prefer the evening when they have a good idea of what they achieved that day, and want to have an action plan ready for the next day. The time could also be determined by time limitations team members may have such as some people being in different time zones.

The Scrum Master acts as a facilitator here and makes sure that everyone sticks to the format. Any potential lengthy discussions are deferred for later. These kind of design discussions are generally held immediately after the Scrum. The SM also documents any new barriers on the board and has his/her work cut out. The Scrum Master may give his/her own update too explaining how s/he worked on particular barriers or concerns the team had.

One practice I have seen followed is that team members move the task cards during the stand-up. This is supposed to give a person a sense of accountability as they move a card from the ‘not started’ to the ‘in progress’ section. Similarly team members feel a sense of achievement when they move a card from ‘in process’ to ‘done’. Many coaches encourage this physical act instead of making updates in some online tool.

Distributed teams can prove to be a challenge for the daily Scrum. If there are only 2-3 persons in a closer time zone, they generally call in. If there is a large team (5+) in a far-off time zone such as another continent, they can have their own Scrum locally, and email updates to the Product Owner and the rest of the team.

The daily stand-up ensures that the team ‘inspects and adapts’ on a regular basis. Everyone is aware of the general updates and what is happening on the team, and how their progress or lack of it may be affecting others or causing impediments in others’ work. E.g delay in coding a certain feature may be blocking the testing story.

The information gained in the daily stand-up exposes potential and current issues and empowers the team to adapt themselves to complete the Sprint goal.

The QA story – and how best to portray it on your sprint backlog

Quality assurance and/or quality control is an integral part of the software development process. It ensures you conform to your requirements, meaning that you are delivering what your customer wants, and isn’t that what we are all striving toward in a nutshell?

Agile advocates test driven development or TDD, and many Agile or Scrum teams use it. But that’s a big topic on its own. I want to focus this post on how you portray testing or QA on your sprint backlog, whether it’s a TDD type activity, or manual testing or automation testing or any aspect of the testing lifecycle be it planning, design, execution, defect tracking, process improvement etc. These are tasks that you would typically have even on an Agile/Scrum team if you follow a modicum test management process. These need to be done for each story on your sprint backlog. E.g if your story is about creating a way to login to your system, or adding an item to a shopping cart, you still want to write high level and detailed testcases for each requirement pertaining to this story, then have a task for executing these testcases, have a task for defect logging if necessary etc. You will probably need tasks for setting up any initial conditions such as test environment or specific data setup. You will need tasks for obtaining approvals for your testcases, or following up on defects etc. You also might need tasks for other admin type activities such as setting up your test tools, assigning appropriate roles to team members, ensuring that your developers are set up right in the defect management systems so that you can assign your open bugs to them etc. etc. etc. The list is endless and you may do some or all of these depending on your organization, your team and the minimum artifacts you need to produce from an audit or compliance standpoint. I have not even touched on tasks relating to regression, integration etc.

Lets pause a second to take a deep breath. Does this seem like a lot of work? QA or testing almost always is. It takes a lot of due diligence to ensure sufficient test coverage and it’s the last step before you release your baby into the big bad world. So how do you portray all this on a sprint backlog? Create cards for each and every small thing, or just clump some things under a ‘miscellaneous’ heading?

This is what my experience has been. As you work on successive sprints, you start realizing the myriad small tasks or things that need to be done to reach the point of say, executing a testcase, and you gradually start creating separate tasks for them. This may appear to be overkill initially but it has its advantages. You increase visibility into what you do, and make the entire team aware of the nuances of a typical QA function. You make it easier for your team to understand your estimates – it is easier for everyone to follow several tasks that are 2-4 hours than having one number such as 20 hours or 40 hours that most will think you pulled out of your hat. This also builds greater understanding in everyone’s mind about the impact any changes to requirements or code will have on QA. So you get it – the advantages are manifold.

Getting down a bit further to brass tacks, I have generally had specific tasks such as designing and documenting testcases, executing them, adding defects as part of specific stories, and then I have a separate story I call the ‘QA story’. All my administrative tasks go here e.g. resource onboarding, tool setup, work requests, status calls, mentoring, knowledge transfers etc. etc.

One big advantage of this is that I already know what most of the tasks are going to be each sprint, and it makes it easier all around during part two of the sprint planning meeting. Each tester can focus on the stories they are going to work on, with only one or two ‘new’ tasks they may need for a specific story. This saves time being an almost repeatable process. Of course, it has taken me time and several different projects to come up with this.

What do you think of this post? How do you portray your QA tasks on your sprint backlog? Do you have different tasks each sprint, or do you feel that you are doing similar things for each story? I would love to know your views and experiences.

Planning Poker for Agile estimation – Thou shalt not be inscrutable!

You don’t need a poker face to win this one. In fact, you need just the opposite. But hold on, let us start this properly.

Software estimation can be your worst nightmare, and no matter how many fancy statistical models you use, you may still end up not being totally accurate. Agile offers a unique method for estimating your user stories – planning poker. Yes, it uses cards, and yes, it is sort of a gamble like the game, and yes, it is FUN. And yet, you end up with pretty good estimates for your user stories, and hence your sprint or iteration. And you get to play this every other week, or every month, depending on your sprint length.

Wikipedia provides some good background on planning poker here. So does Mountain Goat software and http://www.planningpoker.com/. There is an oldish post  here which has several good comments that offer differing points of view and experiences. Ken Schwaber also wrote of this recently.

Ok, so now that we have enough links and sources to read around this, I would like to paraphrase the game simply. Planning poker is ‘played’ by the Scrum team or the developers to come up with grounded estimates for each story. Actual cards are/can be used. These cards have numbers such as 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ? etc. printed on them. This is how the process goes -

• A moderator is appointed by the group. The moderator reads out the story, the product owner elaborates a bit and then everyone thinks about it for a minute or two. A sand clock or kitchen timer may be used.
• At the call of ‘Show’, everyone turns their selected card up. It is important that everyone be quiet until this moment to avoid creating a bias.
• The person with the highest and lowest card explains why they came up with that particular number. This is not to convince anyone; they justify their choice and that’s all.
• The process is repeated where the group thinks for the minute or two and selects a card again. Everyone ‘shows’ and the high and low estimator again explains their choice.
• The card selection process is repeated until the team reaches consensus on a number and that is allotted as the effort estimate for that particular story.

The higher numbers on the cards are more widely spaced to denote the uncertainty that follows large estimates/tasks. These numbers resemble a modified Fibonacci sequence. Distributed teams can use an online tool that is available at http://www.planningpoker.com/.

Planning Poker works because it takes estimates from the actual performers themselves, and encourages dialogue and hence forces people in diverse roles to think about dependencies. There is also some literature on how averaging individual estimates gives better  results. Also, you have actual performers from different functional areas coming up with their numbers as opposed to one higher-up manager( however experienced) assigning a number for the whole project.

What method do you use to estimate your projects - agile or otherwise? Have you tried planning poker yet? Do you think estimating at the story or requirement level by actual performers will give a more grounded estimate?

Sprint plus one – is it the answer to your test automation woes?

Regression testing is an essential function in software quality assurance whether you are working on a path breaking new product, or some age old legacy system. It’s the only way to ensure that your enhancements, bug fixes or new features have not broken any existing code, and to avoid those 2 AM fire alarms (God forbid), when your yearlong project crashes the moment it meets a production environment. Depending on your organization size, culture, budget etc., you probably have a dedicated team that automates the testcases you marked for regression, and there is an automation suite that is diligently run before any production rollout. Whether it is current and has full coverage is a topic for another day.

So traditionally we have been used to this concept of automation very late in the cycle, generally after a battery of other tests have been run and your AUT( application under test) has withstood them. With Agile methodologies, it’s a whole different ballgame. Agile advocates short sprints or iterations, and each of these iterations have to produce a potentially shippable piece of functionality. It means that your features are coded and tested in every possible way. As this functionality builds up every subsequent iteration, you test more and more because you are integrating everything that came before and also testing it. Doing all this manually is a herculean task, and your friendly Agile coach, always around to lend you a helping hand, has urged you to use test automation. But this may not really be feasible.

In Agile projects, the codebase can and does change pretty rapidly from day to day if not from hour to hour. It means you could have a lot of bugs and are almost always rewriting or updating your testcases. It could also mean an application that is not very stable, and automating something that changes every day may not really seem to be a value add. Yet it is as formidable a task to manually test more and more functionality every subsequent Sprint. The ‘Sprint+1’ approach is the answer, according to this white paper on HP.com.

Agile automation: A primer on test automation in Agile projects (http://h20195.www2.hp.com/v2/GetPDF.aspx/c02879554.pdf) suggests that test automation should lag behind, but not more than for one iteration. So we assume that ‘story 1’ is completely coded and tested etc. in Sprint 1, and is automated in Sprint 2. The assumption here is that ‘story 1’ is stable at the end of ‘Sprint 1’. Some of the salient points and/or questions that I can think of based on agile projects I worked on are –

1)  Even if a certain story is ‘done’ at the end of one iteration, it could always have changes and reappear as a new story, hence requiring more work on it and rework as regards test automation.

2)  Test automation should certainly be a separate item on the product/sprint backlog. This will force all stakeholders to recognize and acknowledge that test automation is a necessary part of the project and requires a chunk of time and resources. It will add visibility in terms of estimates and burndown.

3)  Team members can concentrate on manually testing unstable portions and automating stable functionality. A different person could be doing each of these and either can give full attention to the task at hand, since the actual tasks or sub-tasks for achieving either will be different.

4)  Test automation can or should be a story in each iteration with specific task cards for each particular feature, story etc. that is to be automated.

I can go on, but I suppose you get the point. Every Agile team will be facing slightly different circumstances in terms of their company culture, product, technology, people etc. And each of you will need to come up with something that best fits your situation, try it for one sprint/iteration at a time, and keep improving on it based on your retrospectives.

So how are you handling test automation on your Agile project? Do you have a 100% automated regression suite? Do you think you are saving time using test automation? Or are you still happy using manual means for regression? I am eager to know what you think.

How hard is Scrum?

I know this is a loaded question that almost everyone who has ever worked on an Agile team will scramble to answer. Maybe this has come up in some of your retrospectives, about how the team found certain aspects tough to deal with or follow. But I am not talking about your feelings here. This is about Scrum itself, and its personification as it assumes quite an imposing personality. I came across this while reading this article at http://www.controlchaos.com/my-articles.

The author tells us how the scientific approach has taught us to make a hypothesis, test it and then apply it. This is also called the Newtonian or deterministic approach. But this makes less sense as the complexity increases, and the process becomes more empirical than defined.

Scrum is empirical because it embraces change, and evolves with it. Scrum makes things possible, but Scrum does not promise to make them predictable. Scrum is hard because it goes against the basic human nature of trying to simplify everything. As people achieve success with Scrum, they will set higher goals making it more complex to achieve them.

Yes, Scrum is hard. And I also think arts, humanities and basic sciences are underrated in India. If engineering is the topmost trade and the epitome of a fine education, how come no one ever taught me what a Newtonian approach was? :)