Agile methodology and user stories

What is Agile Methodology?

Agile is a software development methodology in simple terms. It is a light-weight development methodology used in a software development life-cycle. Developers of the agile methodology discussed the importance of each stage of the software development life-cycle, where each stage “learnt” or “evolved itself by understanding” from the previous stage.Thus, each contiguous iterations of agile are flexible and efficient in their own way. This helps business developments to respond to any uncertainty or any unforeseen developmental issues.

Okay, got it! But, why Agile?

The initial models used in a software development life cycle had their own drawbacks[1]. The first one, being Big Bang, also known as Code-and-Fix had the developers writing code and fixing bugs as and when they occurred. Thus, software developers had to wait until the end-product was ready, to check for any errors. This involved cumbersome bug-fixing and correcting errors. The next one, being known as the Waterfall model, had a step-by-step procedure to software development. Though it was able to overcome the not-so-good effects of the Big Bang model, it had its own limitations. To be precise, the waterfall model was not able to go back to the previous stage to make changes, just like how a waterfall would not be able to go in an upward direction. Then came the Spiral methodology, which was a little bit better than the waterfall, in that it was incremental and iterative. Further discussions on bringing about a better development model that would be able to address the ever-changing needs of customers and the developmental issues from a business perspective brought out Agile. That’s how Agile was born! It was also both, incremental and iterative and had smaller sprints at the end of which, each team must be able to produce a product.


Fig: Waterfall model


Just on the line! But how do I use it?

Agile works by understanding the roles[2] of each team member of the Agile team. By the term roles, I do not intend to mean that they are fixed and they are repetitive. In a team that practices and abides by the Agile Manifesto, each team member is capable of holding one or more roles. There can be, for example, multiple stakeholders(Oops, that’s a buzz word; I’ll come to it later!), but a single team lead and an agile mentor. Agile in fact, considers all team members to be equal in their stature, be it a developer or a team lead. Each of the team members have their own responsibilities and deliveries, at the end of each cycle. Let’s dig deep into the roles and see what each of them are meant to be.

  • Stakeholder:

A stakeholder is a person who is a part of the agile team, who gets his share of the financial outcomes on developing, executing or maintaining the product. He might also be an end-user to whom the product reaches out, or a senior manager, or just a person who funds the entire project or an external auditing member who audits and reports defects or “oh-not-so-super” parts of the project.

What happens next is like this. There is a product owner, who acts like a middle-man. He grasps the idea from the stakeholders about the project and then, delivers it to the agile team, as exactly wanted. He also makes a list of the deliverables that his agile team might work upon and deliver, resulting in the final product. He also gets the response of the stakeholders and communicates it to the agile team back again. This way, the corrections, if needed, could be done. Apart from just doing the middle-man work, he also defines the budget for the entire projects, grafts out the project plan and sets goals, may send the completed project-part back to revision, in case if there are any changes, during each sprint.

  • Team Lead:

A team lead is a person who guides the team members of the agile team. The team lead focusses on how to motivate and pull the team together, towards achieving the goals and targets that are set. The team leader may conduct small, 10-minute scrum meetings(oh no! what’s that? I’ll explain later fellas), during which, each individual team member should discuss their own short-term goals that might culminate in achieving the end result.

  • Agile Mentor:

An agile mentor is a person, who is well-versed on agile principles and acts like a coach. He delivers his experience with agile to the entire project team. He also provides feedback, if necessary and guides the team towards reaching the target, faster. He might motivate slower-performing teams with different agile approaches and might also urge good-performing teams to do better, hence the name.

Apart from the above three, there are also individual team members, product testers, technical experts, etc.. These roles and their names might differ from each team, based on how they operate.

I get a fair idea of how agile teams work, now. But is there more?

Sure, there is. Now comes the planning part. How do members of the agile team plan[3], according to the agile “manifesto”. The teams that follow the agile manifesto, usually divide the entire project plan(ah, thats right! This project plan is proposed by the product owner) into stages during which they can release their product deliverables. This is when iterations come into picture. These stages are called development iterations or sprints(like I said before). These are tracked by the team members so that they do not fall short of any expectations or are not running late. There could also be a daily ten-to-fifteen-minute planning which is the scrum meeting that discusses plans for the day.

Next, let us dive into the user stories. User stories are small sentences that tell what the user must do, as a part of the system. They are often used along with agile methodology on the basis of what the business system must provide. They are similar to use-case diagrams, differing in the way they are expressed. They follow a specific template like the one below:

As a user <doing this role> I want <to be able to do this> so that <I achieve this (some goal)>

User stories are generally written in short post cards and a collection of such user stories is called a product backlog. The customer representative, or the product owner as he is called, generally discusses the user stories with the team and comes out with solutions on what the user really wants. User stories do not follow a specific or strict, rule-driven template as the one above. They can be anything, as long as they are short and discuss the requirements. Yes, they are written down as sticky notes and can be put up anywhere, there is, however one curbing factor that smashes down its ease of use. Since they are short, two or three line descriptions, they may not convey the full requirements and may miss out on something that is of less importance in the initial stages but might gain more importance later.


Fig: An example of user stories


The next one is the estimation phase. This is generally done by the product owner. While setting up the goals for the tam, the product owner must estimate if the team is capable of such a thing and if so, what might it cost. Other than the product owner, the agile team members also estimate their work, in terms of complexity, that they can do.

Trivia: The Planning Poker is usually used, for determining the estimates, based on user stories. It works, with the team members analyzing the user stories and writing down estimates to achieve the target based on the user story. The team members then discuss and reach a consensus.

The other smaller phases are the ones that track down the speed at which each iteration is completed, developing the product and testing it to make sure there are no faults or errors, integrating the results of each iteration into the final product, reviewing the final product and collecting feedback, if any and incorporating them.

Okay, you said you will tell me what Scrum is. What’s that?

Oh, yes. During the planning phase, comes the scrum. It is a framework that helps the cross-functional agile teams in working together, planning for the project and achieving the target on-time. The scrum was developed because the conventional models discussed before were not able to adapt to the changes in the requirements and the subsequent iterations.To be able to discuss and successfully incorporate those, the Scrum was developed. It usually works by putting forth questions and trying to answer them, thereby discussing about the necessary changes.

Apart from the product owner and team members, the scrum also introduces a “scrum master”, who is neither the product manager nor the team lead, but is in fact, the person responsible for discussing the team’s abilities to deliver the product in case of impending changes. The scrum master also does all that is necessary to increase productivity. For example, he discusses with the team members in case there is any difficulty in proceeding and tries to clear that as soon as possible.


Fig: Scrum functionality


The meetings to be held with a scrum master are, the first one being the sprint meeting which occurs for every iteration. At the end of each sprint cycle, a sprint backlog consisting of the goals and time needed to accomplish them are created. The second one is the daily scrum meeting, which is a ten-to-fifteen-minute meeting as discussed above. The daily scrum meeting is attended by the team members along with the team lead. They discuss about the work done till now, the work to be completed further and any other obstacles preventing them to achieve their goal. The third one is the sprint review and retrospective which are usually the meetings held during the end. The agile team members usually discuss and review their finished product. The sprint retrospective discusses on what was working during the entire sprint and what could be done further to improve the process during the next sprint.

I read a term called prototyping somewhere. How is that related to agile?

Incomplete versions of the product being developed are called prototypes[4]. In some places of agile development, prototyping is used. The usual questions to be addressed are, what kind of prototypes are used, and how complex are they. There are three steps in prototyping: determine needs, build the prototype and evaluate the prototype. This cycle repeats for every prototype until the desired results are achieved. Once the requirements are gathered and the prototype is built using the prototyping tool, it is sent to the stakeholders back for evaluation and suggestions. Feedback is provided on the prototype which addresses questions like the good and bad parts of the prototype, what else can be done to improve the prototype, etc. Agile teams usually do not build prototypes for the entire project in advance; it is usually done in stages. This is because, no one ever knows when the requirements might change.


Fig: UI Prototyping in Agile



Okay, we now learnt all the basic things that are needed to know about the agile methodology. Agile can be used not only in software development, but also in other industries such as medicine, automobile development sectors, food (cooking), etc. I read somewhere, that Agile could be used even in child development! Weird as it might seem, it actually makes sense to raise a child in stages! Yes, Agile in fact is a lot more than what we all know!

List of primary references:

[1] Lehman, T.J. ; Almaden Res. Center, Almaden Services Res., IBM, San Jose, CA, USA ; Sharma, A., Software development as a Service: Agile ExperiencesSRII Global Conference (SRII), 2011 Annual.

[2] Hoda, R. ; Dept. of Electr. & Comput. Eng., Univ. of Auckland, Auckland, New Zealand ; Noble, J. ; Marshall, S., Self Organizing Roles on Agile Software Development TeamsSoftware Engineering, IEEE Transactions on  (Volume:39 ,  Issue: 3), March 2013.

[3] Scott .W Ambler, Matthew Holitza, Agile for Dummies, IBM Limited Edition.

[4] Tiago Silva da Silva, Angela Martin, Frank Maurer, Milene Silveira, User-Centered Design and Agile Methods: A Systematic Review, 2011 Agile Conference.

 List of secondary references:

1. Gaurav Kumar, Pradeep Kumar Bhatia, Impact of Agile Methodology on Software Development Process, International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 4, August 2012.

2. Scrum Basics:

One thought on “Agile methodology and user stories

  1. waichengleong says:

    It is very wonderful that your blogs have a lot of sources. The information is very detailed, and the images are helpful for the audience to understand complicated materials. I also like your interactive writing style that communicates with the audience. It is easy to focus and understand the materials, as you divide sections according to different topics, and the format of the blogs is clear. Besides, you include a lot of other topics that provide extra information for the audience.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s