Agile FAQ

The following is a collection of 10 frequently asked questions about Agile methodology. You’ll find suggested best practices that come directly from CA Agile Central's coaching team, who have years of experience guiding organizations through Agile transformations. Click a question from the list below to jump directly to a topic:

How do we know if a transition to Agile will work? Has anyone else like us done this successfully?

Software development is very difficult, so a methodology transition is not a guarantee of success. Many products fail to be delivered on time and within budget, and others fail to meet expectations. Agile is not a silver bullet. A fatally flawed initiative will still fail, but with an empirical approach like Agile, you will either fail sooner or use feedback to change course.

There are many who have experienced success with Agile. While every individual, team, or organization is unique, they all face similar challenges. Regardless of the business or technology domain, we all want to deliver early and often, and pull quality forward. The question is not, “How Agile can we be?”, but, “How good do we want to get at building software?”.

What about documentation?

One of the popular myths about Agile teams is that they don’t produce documentation. The reality is that Agile teams know that face-to-face conversations are the most effective means of communication. Documentation is produced when there is business value, not because “we always did it that way before.”

You don’t often see Agile teams creating detailed requirements documentation upfront. With business and development working more closely together there is less dependence on the written word, allowing teams to defer commitment until the maximum amount of information is available. Where documentation is necessary, you should make time within the iteration to complete it. If you wait till later, you will accumulate technical debt that will impede your ability to release .

Does Agile work for distributed teams?

Absolutely. We have many customers who are very happy and successful with their distributed teams. Although face-to-face communication is the most effective means of communication, it is often not feasible to have co-located teams. In our ever-changing world, where companies are offering employees a better work/life balance and are conscientious about the environment, we see more and more distributed teams.

What is the right size for stories?

Stories should be the right size for their purpose. If you are planning an iteration, you need to ensure your stories are small enough to be completed in an iteration. On the other hand, stories appearing on a product roadmap might span multiple iterations, and to spend time breaking those down may not be economical. Sometimes we see teams breaking down stories towards the end of the iteration as they try and de- scope to meet their iteration commitments; this is usually a sign that stories are too large. So, create stories small enough that you can correctly prioritize scope, but not so far in advance that you risk wasting effort.

What is the right team size?

The magic range we like to use is between five and nine people. Once a team grows, meetings last longer and the amount of not-directly-relevant information increases. There is also a danger that individuals will start to question the value of everyone attending daily stand-ups and planning meetings. Of course, it may not be that easy to split the team, and it can add overhead. Use the retrospective meeting to generate ideas for how to proceed with the larger team or what the best split options are.

What if we can’t break down our stories?

Although many new to story writing anticipate difficulties with this in reality it usually sorts itself out. For example, close your eyes and think about what you are going to do immediately after reading this. You just broke down a story. Yes it’s probably a very small task that you don’t need to detail on a backlog , but it is part of something larger and has identity.

We are good at breaking down stories, we just need to get accustomed to doing it at the right time and at the appropriate level of detail. We don’t do it all upfront; it is a continuous process. As we descend through the levels of Agile planning and discuss our stories, our dialog drives the story breakdown. For example, as we prepare for planning our next iteration we will have discussions about some of the choices for the stories we have slated for that iteration. The decisions we make will yield either acceptance criteria for the stories or new smaller stories that can be independently scheduled.

Can we change a story or task after the iteration has started?

The tasks in your iteration should accurately reflect the work that needs to be done. If you underestimate a task, then the hourly estimate should be updated as soon as possible so the rest of the team has visibility into the latest status and can offer help where needed.

Stories are not expected to change during the iteration; the process of writing the acceptance criteria, estimating the story, and tasking out the story usually uncovers all needed information. If there is a request to add to the scope of a story, then the team should ask the product owner to consider waiting for the next iteration. If the scope change cannot wait, then consider the impact and if significant, cancel the iteration. Removing scope is a much easier question to address. Stop doing something as soon as it is discovered to be unnecessary.

How do we write stories from the users’ perspective if we are delivering internally?

Think about who the story will be delivered to and what value they will get from that story. It should always be possible to express something in a way that articulates value. Many use the "As a (type of user - who), I want (some goal - what) so that (some reason - why)" user story template. The last part, the (why), is very important, and should not be taken lightly. If we cannot justify the need to build a story, perhaps the story is not valuable and needs to be reconsidered.

How do we estimate delivery date and cost?

Every successful business needs to set expectations around delivery date and cost and an Agile organization is no different. An estimate is by definition a guess, so there can never be any guarantees. A key tenet of Agile estimation is that we estimate at the work product level, not the worker.

With an iteration-based approach like scrum, we can use the velocity of our teams to predict both the expected delivery date and the cost of items on our backlog. With a flow-based approach, we would use cycle-time and throughput to set expectations. With both approaches, we need a predictable incremental delivery model. Without a stable cadence our first cut estimates are little better than we experience with a traditional plan-based approach. However, if we can commit to a small-batch, rapid feedback rhythm we have the ability to check-back early, and provide higher fidelity estimates a lot sooner than a traditional approach.

We are really struggling to dedicate people for the iteration, any suggestions?

If you have people wearing multiple hats you are losing a lot of productivity and impacting throughput by context switching. Prioritize ruthlessly and limit the work in progress to force one thing to be completed before people start on something else.

It is okay, and even expected, that from time to time the group will need rely on the expertise of specialists outside the team. The work of the specialist should be planned and managed just like other members of the team.


Need more help? The CA Agile Central Community is your one-stop shop for self-service and support. To submit feedback or cases to CA Agile Central Support, find answers, and collaborate with others, please join us in the CA Agile Central Community.