QA in Scrum

March 17, 2009 - 4 Responses

I have seen the tension of uncertainties in the eyes of QA people in reality and in the web community while we were newborn Scrum-babies. The reason was, Scrum defined only three roles – and it wasn’t clear how QA will work in this “cross-functional team” scenario. Is QA engineer a waste? Over time, Scrum teams around the globe got valuable experiences and learning and all the tensions vaporized quickly. Whatever processes we follow, the basic SDLC will never change and specific skills & expertise will always be needed in the various phases of the life cycle.

What are the responsibilities of a QA resource and how s/he will look like in a Scrum team?

To me, QA person (whoever works to ensure quality in the team, not just the people with QA designation) reduces waste from everything going on in a Scrum team. QAs are not testers only to report Bugs, Issues… (wastes) at the end, basically they work from the beginning – even can start with the POs to improve the quality of user stories. They can pair with the developers during the implementation to clarify the requirements; remind them with the acceptance criteria, boundary conditions & business constraints; help to develop unit tests; help in testing at Developer’s PC and so on. QAs can develop system test cases and acceptance test cases and can involve the whole team to perform the test in early state, whenever someone is ready and available, just-in-time.

While team passes thru the testing and stabilization phase, QAs should take lead (NOT to control but) to plan, organize and involve the whole team in the testing work and to keep people motivated just like the SM. Reality shows, most of the developers don’t prefer the testing work (they suppose to develop, right 🙂 ), so along with SM, it’s the QA who can keep the vision and goals visible to the whole team and perform everything needed to keep the motivation level high. Sometimes funny testing ideas, funny test data, fun games/competitions  with testing – help the team to stay on top of the testing work.

QA can help the SM to maintain the agility of the team, to follow up on Scrum processes and make adjustments if needed. QA can provide feedback to POs from the testing experiences and that can help POs to develop better user stories with enhanced acceptance criteria. Based on the findings from the team, QA can help POs to modify/update/enhance existing user stories.

QA engineers & Developers just create the perfect balance in the team and produce the required momentum to move faster while reducing wastes and increasing quality.


Story points battle: Why & How

March 7, 2009 - 4 Responses

This article is not for the beginners want to learn the basic of Story points and related Poker bidding technique. If you are familiar with such stuffs but struggling to get the deep meaning of it and facing difficulties to implement it in real life – this article is just for you.

Being an Agile practitioner and working with the team to introduce Scrum in the company from scratch, this is how I see the challenges with Story points:

  • Most of the beginners tend to estimate Story points considering the one-dimensional unit “Hour”; try to convert Story point to Hour or Hour to Story point. We are familiar with hour based estimation and find it easy to think. But “Size” of a User-story/Requirement is not just the hour.
  • It is evident that different user-stories with same story point are taking different time length (in hour). It also varies with different teams.

 Wondering why is such?

  • Guesstimating a requirement is inherently a chaotic process, varies requirement to requirement and project to project and people to people. A requirement is definitely NOT one dimensional and depends on lot of internal and external factors (people, environment, customer, skills, experiences, domain knowledge, technologies, dependencies, unknown risks, management…you name it). Moreover, requirement evolves with time, knowledge and context. Such a complex “thing” you cannot easily estimate just by one dimensional “Hour”.
  • Requirement cannot also be estimated considering the LOC or number of features or number of input/output forms [It is an old issue and Google will provide you lot of materials in support of this idea]

To me it is our “feelings” that helps us to understand the size of a piece of requirement in our mind thru a complex biological procedure that we cannot depict mathematically. But we still can “feel” it – which is good to start with. Can you define feelings by some specific unit?

So to me, unit-less Story point is a natural selection to capture the “feelings” about a requirement during inception – when lot of factors are unknown. It is calculated as ratio, as the relative values with each other. If you know what it takes (effort, procedures, complexity etc.) to cook a “chicken”, then most probably you can “feel” what it will take to cook “beef” or “fish” and can compare their respective efforts. Numerically, if “cooking a chicken” is 5, then what do you think “cooking a fish” will be?

Some people may say 8, some may say 3 – actually both are correct in a sense those are just “feelings” based on behind-the-scene calculation (past experiences, domain knowledge & skills, personal point of view & context and so on…). That’s why during the Poker bidding, all member should discuss all the available information to come to a consensus.

More Problems from my personal experiences:

  1. People cannot see the real advantages of estimating story points straight in front of their eyes
  2. Not every Scrum member is aware of the goals & objectives of Story points
  3. and most importantly, some times we made the poker bidding session boring and worthless because of the very immature user stories from PO/Client (team gets tired trying to estimate the size of a black hole they have never seen!)

What happened in my case was unfortunate 😦 PO stopped the poker bidding – no more story points. Let’s get straight to the detail estimation of the SBL items in hours and concentrate on the short term sprint goals. Seemingly team is also happy by avoiding the long tiring poker bidding session.

Being a Scrum master, I was not that convinced but I also agree with the situation. After doing some homework, I proposed a model to resolve the three issues mentioned above. To my surprise, my proposal was approved and all are convinced now we should continue the Story points, Cheers! 🙂

I set the specific tangible goals for capturing story points to address issue #1 & 2 above, which is something like:

We will calculate the total story points per sprint per team and respective SM will preserve that data for future analysis that includes but not limited to: Team’s performance and improvement trends, team’s actual capacity, organizational factor to convert story point to time & budget etc. [specially measuring the team’s performance improvement is a key factor for understanding if we are doing Scrum/Agile correctly and all bought in the concept]

I came up with a new idea to avoid long bidding session as well as bidding on immature stories (issue # 3). I propose the following scenario:

PO presents the detail PBLs to the team. Team comes back to the workstation for self-study and realization what PO just told (we practiced it this way). Before going to the tasks breakdown (SBLs) and estimation session (after less than an hour or so), SM will send a web link where each member will fill up the number/point against each story and submit the form. The web form looks like this:


I have created this form using Google-Form (easy and free :)) and the submitted data automatically stored in a Google-Spreadsheet like below (no coding :))


As team gets this form when they are “sufficiently” knowledgeable on the requirements and no chance for face-to-face unnecessary discussion (we are not writing the bible), the whole Poker bidding takes less than 5 minutes! SM will take the bidding summary to the planning session and quickly discuss with the team to resolve only the conflicting PBLs (reality shows very few at this point of time – good news :)) and then count the total Story Points. SM will preserve this data per sprint for future usages as stated by the objectives.

Each team needs to find one starting value (baseline) for a feature that every member can conveniently understand. Each member of the team will compare this baseline value to determine the story points of all the new PBLs. For best result, one team should use the same baseline for all of their sprints.

I also introduced a new concept that I call “Actual Bidding”:

After the sprint is completed, SM will again send the bidding form, before the retrospective session (or any other suitable time), to be filled up by each member based on actual experiences. Again it will take less than 5 minutes. SM will analyze/compare the data from both the bidding and feed the team to improve their bidding skills. 

Long live the Story Points and Poker bidding 🙂

Distributed Scrum: Breaking the geographical and cultural barriers

March 6, 2009 - 12 Responses

The software development company I was working implemented Scrum back in 2006. The setup was like, couple of Scrum teams were working in Europe and another couple of Scrum teams were working from offsite location at Dhaka. Four separate teams were following Scrum by textbook. Teams were conducting daily Scrum of Scrum (SOS) to synchronize them and to resolve inter-dependent issues.

After running for a year, it was evident separate teams working on the same project and for the same client (means same vision) were causing unnecessary issues and delays. Moreover the expectation gaps due to remote locations and cultural differences became a major pain that was creating lot of emotions at both sides. 

By that time, teams got familiar with Scrum framework, understood the basic principles and were convinced that Scrum improved the delivery and quality significantly. So we decided to continue with Scrum and stretch it beyond its limit. We formed distributed Scrum teams consisting members sitting thousands of kilometer away. Some of the objectives were:

  • Reduce the inter team dependencies
  • One team, same vision
  • Transparency everywhere
  • Reduce Onsite-offsite psychological & cultural gaps
  • Quality-Quick delivery

Fantastic objectives but lot of implementation challenges. We had customers at various locations across the globe; we had Product owners, Developers, QAs, Infrastructure teams – all existed in multiple geographical sites. Infinite number of how-to questions were floating around us.

How to stay close
How to attend meetings
How to use Taskboard
How to code review
How to check-in
How to build frequently
How to demo
How to …

Fortunately we were using Microsoft’s Team Foundation System (TFS) as our only authentic development & management tool. We introduced “Scrum for TFS” to handle the Scrum related processes.


TFS solved our check-in and frequent build issues. Scrum for TFS gave us the opportunity to centrally create the product backlog, tasks and other relevant items. Based on the APIs provided by TFS, we built our custom virtual Taskboard. POs can create user stories, teams after breaking it down create tasks or bugs and all pop up in the virtual Taskboard. Members (does not matter where s/he is) can pick tasks from TFS and tasks status is updated on the board in real time. Team can always look at the Taskboard just like the whiteboard with stickies on the wall. Things were looking pretty cool towards our journey to distributed Scrum.


No wait, still lot more challenges ahead! Attending meetings. Fixing local issues. Transparent and continuous communication among members…We introduced Global and Proxy Scrum Master (SM) concept. Global SM is the natural SM of the team as stated in the textbook. But staying thousands of kilometer away, Global SM cannot facilitate and handle remote issues (some developer is sick or mentally upset, local interferences, booking a meeting room and so on). Proxy SM just fitted in our distributed picture nicely 🙂

What about open communication? We agreed to use Skype as our natural communication tool among members from different locations. We provided Webcams so that verbal communications look like almost real and people can see the facial expressions – it reduced the expectation and cultural gaps dramatically! On top of that we introduced GoToMeeting to share our desktops. We can talk all the time (PC to PC voice call is free in Skype), we can see each other (webcam) and we can show our codes, design diagrams or anything to others (GoToMeeting). Hey isn’t it the Scrum team as stated in the textbook sitting in the same room – talking, shouting, pair programming, code reviewing, planning, attending daily scrum?


After all the setup and moral boost, rest things fall in place quickly. We shifted our 15 minutes daily Scrum to a common working time so that all members from different time zones can participate. It is definitely not in the morning for everybody. Members of such locations introduced a short local morning scrum to address immediate issues to start their day and then they attend full Scrum meeting at the preset common-for-all schedule. The Sprint planning meeting, sneak preview, demo, retrospective, code review, design discussion – all such meetings were conducted always on the overlapping working time period.

After all such initiatives, I visualize my distributed Scrum team as a real Scrum team that follows all the basic Scrum principles, makes more business sense and handles real life situation where more and more software companies are outsourcing their work and dealing with distributed team members.

video-conf[Image taken from web, unknown source]

I consider myself lucky being a Scrum Master and Agile practitioner by working both at offsite and onsite locations with such great teams.

Migrating to Scrum: A real life scenario

March 5, 2009 - Leave a Response

About 4 years ago, I got an opportunity to join an experienced team to build up a joint-venture software company in my country (parent from Europe) that has the strong objective to implement CMMI framework from day 1 and achieve level-3 within 1.5 years both at onshore and offshore sites. I was overwhelmed as I already had formal training on CMMI from QAI (India) experts and had hands on experience (as PM as well as PEG member) to implement processes in real teams to reach level-3. As readers can understand, I didn’t miss that once in a lifetime chance!

Me and my team flew to Europe for a month to have formal training on CMMI by Trimentus (India) and to kick off the process formulation and implementation phase in a ‘begin all with best things’ approach. Aha wait…I am telling the CMMI story again, confused with the title? Readers, gimme a moment, I’ll come to the point.

We tried CMMI for sometime, soon realized it is too heavy for a company like us and also for the values we believed in. We turned to MSF Agile (Team Foundation System from Microsoft was our core tool) and then thru a dynamic movement from our European CTO – we hugged SCRUM for the first time. Readers please note the interesting migration path – I personally have gone thru all of them and that’s why I got the opportunity to better understand the differences among traditional and agile approaches and why do we need Agile/Scrum.

Being the only Project manager at the offshore side, I faced multiple challenges at the same time. Learn the values of Scrum and act as a Scrum Master for the new Scrum teams. Kept heavy communication and coordination with onsite Scrum practitioners to achieve same level of expertise and disciplines across the organization without any ambiguities. And most importantly, convert from a PM to a true Agile Leader.

We started slowly taking baby steps. We formed separate scrum teams at onsite and offsite. We introduced daily SOS among cross-regional teams. We started everything by scrum book, bit by bit. Even I was using a digital timer to maintain the time box everywhere. After few sprints with lot of hurdles, we started feeling the comfort and experienced the real advantages of Scrum. Then we started playing with scrum – push it, press it, stress it – to meet our custom needs. Individual teams started implementing the same framework in their own way best fit to their own domain and context. Back in 2007, we moved to the distributed Scrum model – one team, one goal, one code base, members from different geographical locations.

Since then we are eating the best fruits of Scrum and everyday inventing new meaning of it and assigning new meaning to it. In my next post, I’ll try to explain some of the tips and techniques that we were scrumming!

Agile bigbang created my universe

March 4, 2009 - Leave a Response

My introduction to agile software development model was interesting and sad at the same time! I was working in a renowned offshore company in my country (Bangladesh) that had a strong focus on CMMI framework and was fully ready to achieve level-3. Being a Project Manager of US & Europe based offshore projects for a long time and as an active member of the Process Engineering Group (PEG) – I have learned, practiced, experimented a lot of processes in various teams with different projects under the shadow of the RUP and CMMI. I got formal training twice on CMMI from couple of leading QA organizations from abroad.

Enough of my history, lets get back to the point. During 2004, I was assigned as a PM in a new team with a new project from USA. I myself along with my dynamic QA planned and tried to implement all the best practices and best processes in the new team. Don’t ask me how challenging the project was – we 6 members worked 6 months continuously almost without any weekend or vacation (believe me!) to meet the unique requirements from the client and at the end, we failed!

I looked back myself to find out the causes of the great failure and surprisingly identified the most important one – everything of that project was dynamic in nature, but we weren’t! The team was new with dynamic attitudes. The requirements were so volatile that things got change between morning and evening. The architecture was evolving with time in many dimensions. It was an innovative product to display business relevant unique dashboard information to various levels of employees and every time we built something, new ideas were popped in and new requirements were born. Nobody – customer, product owner, business analyst had concrete acceptance criteria in mind.

Hmm….with my broken heart, I was searching around to find a remedy to manage such very dynamic projects and bring success out of it. At that time, my boss voluntarily gave me a new book that none had read yet in the company. It was ‘Agile Project Management’ by Jim Highsmith. I started reading casually first, after reading few pages I just dove into that! Bingo…Eureka…I am no fool, I got my tool! And the journey started…

I think good exposure of the CMMI and RUP, helped me to deeply understand the need and scope of the agile concept and also taught me how to bridge two different worlds in needs with comfort and without conflicts.

I wandered lonely as a cloud

March 2, 2009 - One Response

I wandered lonely as a cloud
That floats on high o’er vales and hills,
When all at once I saw a crowd,
A host, of golden daffodils;
Beside the lake, beneath the trees,
Fluttering and dancing in the breeze.

Continuous as the stars that shine
And twinkle on the milky way,
They stretched in never-ending line
Along the margin of a bay:
Ten thousand saw I at a glance,
Tossing their heads in sprightly dance.

-William Wordsworth