Delivering a project and presenting to a multi-level audience

In the previous blog post we have seen how a project is handed off to the client and how an end product is delivered. In this post let us focus on the ways of presenting a project to the multi-level audience.

Here are some of the key points that might be helpful while presenting to a multi-level audience:

Know your audience. This is the first and foremost thing a presenter must take into consideration, while thinking of presenting something. Given the set of audience, we must take into account their backgrounds and who they are. There might be stakeholders, technology enthusiasts or beginners among the audience. Based on all such attributes, we need to prepare a presentation format, that appeals to all the sections of audience. This is an ideal case and as this might not happen all the time, we should try to be as close as possible to this benchmark. For example, a functionality can be explained using graphs for technical audience and the same functionality can be explained to naives using animations.

Know your equipment and capabilities. We should be aware of the audio and visual equipment, that will be provided for presentation. We must determine if we need a chalkboard, whiteboard, laser pointer or whatever that is comfortable for us to elaborate the concepts. We must also make sure if we can get some assistance in the case of equipment failure.

Review before presentation. We must take opinion from both technical and non-technical persons before planning to present something. As we have discussed earlier that there might be audience with different backgrounds, we must make sure that they understand it. While reviewing, if a technical person understands the presentation and non-technical person doesn’t understand it, we must make some changes in a way that also appeals non-technical person. Doing these things in advance, might increase the confidence levels of a presenter.

Prepare critical questions. We must prepare some critical questions in advance and make sure that the presentation answers them. For example, if the challenges for a project are missed in the presentation slides, and if anyone from the audience is interested in knowing about them, it might take some time for the presenter to recollect the challenges and present them to the audience. But, if there is already a slide for challenges in the presentation, that will be very easy for the presenter to answer them. Preparing critical questions in advance, might not only help in being clear about the concepts, but also helps us in answering any critical questions posed by audience.

References:

 [1] (2014, November 29). Retrieved December 1, 2014, from http://web.cse.ohio-state.edu/~bmathis/2501/Technical-Presentations-Book-1-Strategy-Preparation-and-Planning.pdf

Advertisement

Handing off a project to a client; what are the risks and challenges?

Handing off a project to a client, is the final and very important phase of a project. Whatever the effort we have put in during the product development, goes waste if the project is not handed off as expected.

Here are some of the key points that should be met while handing off a project to a client:

Have a clear vision for the end Product. A project has to go through many phases before coming to the completion. In the case of Agile, these phases are referred to as Sprints, where each sprint has a backlog and the all the tasks in it should be completed before that particular sprint gets completed. In this manner, by the end, an end product should be ready, before the completion of final sprint. Now, what if the end product achieved is not the one we desired for? So, in order to avoid these conflicts we should have a clear vision for the end product, from the beginning itself and we should cross check our vision with the end product obtained at the end of every sprint, so that we will not deviate our work from the vision we had.

Decide the date for handing off a Project. This is one of the most important things, a team should follow before delivering an end product to the client. There will be lot of milestones in a project and if all of them are successfully met, then the end product should be delivered within the date specified by the team. In some cases the deadlines might get extended because of the change in requirements and in such cases the client will be known about this in advance and hence there might be minor changes in the project hand-off date. The two cases mentioned above will never bring negative impact for the team. On the other hand,  handing off a project to the surprise of the client or not handing it off when they expect it, is not at all the ideal way for ending a project.

Provide proper documentation. Whatever the application we develop or whatever the feature we implement, is of no use, if the end user doesn’t understand how to use it. For example, in our case, we are working on Academic Scheduling Project and there is a application form in this system, using which a department requests for class rooms to conduct courses. We should be able to provide proper documentation to the department, so that they can make use of it while using the Academic Scheduling System. Providing proper documentation makes lot of things easy to the end user.

Get the project report signed off. Before delivering the end product we must also make sure if all the client requirements are met. We should prepare a final report which showcases all the work we have done and the report should also include the requirements which are not met, so that the client will be aware of them. For example, in our case, for the Academic Scheduling Project, we have implemented the ‘add form’ feature, and so the ‘change form’, ‘drop form’ which we haven’t implemented should be reported separately. After doing all these things we should get the report signed off.

End Product Delivery. Finally the end product should be delivered to the client, in whatever the way that was mentioned at the beginning of the project. Hosting the product on cloud servers or handing it as an executable file are some of the ways of delivering the end product to the client.

References:

[1] How to Hand Off a Project Successfully. (2014, November 29). Retrieved December 1, 2014, from http://cobaltpm.com/project-hand-off/

What five technical skills are employers seeking? What five soft skills put you on top?

Skill is the ability a person possess. In the remaining part of this post let us see how this applies to the IT Sector. During the Job Interview, employers look for applicants with two types of skills: Technical and Soft skills. Technical Skills are the skills needed to accomplish mathematical, computer, engineering or scientific tasks. On the other hand, Soft Skills are skills that enhance the interaction abilities in a person. ‘Communication Skills‘ is one such example.

TECHNICAL SKILLS:

Programming and Application Development. Companies can improve brand and productivity with technology and software. Applications can be user friendly and always create better web presence for a process flow. This is the reason, because of which most of the employers are interested in persons with application development background.

Data Scientist. Data is growing day-by-day and so, there is a need for analyzing all that information in order to find the trends and bring new products into the market. Big data is one among the top most priorities for companies. Candidates with strong mathematical and statistical backgrounds are desired for this domain. However getting the right people in this domain is a bit challenging.

Cloud. Now-a-days most of the companies are hosting their servers on clouds like Amazon and Salesforce, in order to make efficient utilization of the resources. So, obviously there is  demand for persons having skills related to cloud infrastructure and Networking.

Project Management. Requirement for programmers and the need for project management skills, go in parallel. These two things are responses to the needs of businesses. Projects and Project Managers establish a direct proportionate relation.

Security. Security has been a major concern for IT Industries. The task of protecting systems and streaming data is becoming complex because of which the demand for security professionals is increasing. There is a good scope for encryption technology and security related systems.

SOFT SKILLS:

Communication Skills. Projecting an idea and expressing our thoughts are very crucial in any job industry. It is with communication skills, we can achieve these two important things. In the case of IT Industry, lots of presentations and demos related to Project take place very frequently. Having good Communication Skills, helps us a lot in handling these tasks efficiently.

Adaptability. The needs of an organization keep changing and it is very important to grow our skills in order to adapt to them. Passion to learn is the key for this to happen. It would be great, if we can explain our adaptability, on resume or cover letter, as it would help us in our career growth.

Problem Solving. Most of the time employers look for problem solving skills in potential job seekers. They don’t expect a complete solution, however the approach for problem solving is very important and this is what employers look for, in job seekers.

Critical Observation. Critically observing the things is more important than presenting the facts. Here is an example for this, Analyzing and interpreting the data is more important than collecting and manipulating it. The story that the data tells should be presented.  This is what, critical observation means.

Teamwork. Employers are interested in employees who like working in a team. An employee should be able to play the role of a leader, sometimes should be a good follower and work with others in an organization to attain a common goal.

 References:

[1] Six Soft Skills Everyone Needs. (2014, November 29). Retrieved December 1, 2014, from http://career-advice.monster.com/career-development/getting-promoted/six-soft-skills-everyone-needs-hot-jobs/article.aspx

[2] 10 hot IT skills for 2013. (2014, November 29). Retrieved December 1, 2014, from http://www.computerworld.com/article/2492784/it-management/10-hot-it-skills-for-2013.html

Social Media and Branding

Social media is one of the most powerful branding tools available for personal branding and corporate branding. Personal branding is the practice of people marketing themselves and their careers as brands[1]. Corporate branding is the practice of using a company’s name as a product brand name[2]. The points in this blog post are mainly focused on using, social media for personal branding.

Social networking sites for Personal Branding:

• LinkedIn is the professional social networking site where we can apply for jobs, join groups and converse with Professionals.
• Twitter is a place where we can improve our branding by posting blog url’s and articles related to technology stuff.
• Facebook helps us create pages of our interest, which we can share with our friends thus increase its brand
• Klout monitors our online personal brand’s effectiveness, and gives an online score.
• about.me helps us to create a personal page, that is very easy to format and coding is not needed for this.

To know more about how LinkedIn can be used for branding, follow the link to my previous blog post http://bit.ly/1yWVuCI

Methods that help us in establishing a brand on social media:

Own the address space. We must make sure that we’ve locked down our virtual address, before we even think of putting something there. The profile names and URL’s should be close to our business names.

Be consistent. We must be consistent all the time while we brand ourselves in social media. Consistent, in this context refers to be with same values, core message and brand voice all the time. If we’re a technical brand, we should create technical content.

We must put ourselves in their shoes. Reviewing our social media brand is very important, once we create a brand for ourselves. We can ask our team members to review our brand and however they’ll be sympathetic to our goals. So, it is better to take the feedback from the customers and we are very lucky to have platforms to ask such things.

Be relevant. We must always make sure that our branding is relevant. For example, if we’re launching a new product, we shouldn’t just post about it. Instead, we should do something different that captures the user’s attention.

Trust the customers. No one can build a great brand by themselves. We need a lot of public support and any other support as well to greatly build our brand. We should train our existing social audience in a way, such that they’ll take some responsibility in building our brand. This responsibility comes only when they trust us. They trust us when they feel our service is commendable and the products are quality oriented as well.

 

References:

[1] Personal branding. (2014, November 29). Retrieved December 1, 2014, from http://en.wikipedia.org/wiki/Personal_branding

[2] Corporate branding. (2014, November 29). Retrieved December 1, 2014, from http://en.wikipedia.org/wiki/Corporate_branding

[3] How To Boost Your Personal Brand with Social Media [INFOGRAPHIC]. (n.d.). Retrieved from http://theundercoverrecruiter.com/infographic-how-to-boost-your-personal-brand-with-social-media/

[4] Seven tips to establish your brand on social media. (n.d.). Retrieved fromhttp://www.theage.com.au/small-business/smallbiz-marketing/seven-tips-to-establish-your-brand-on-social-media-20140225-33fn3.html

LinkedIn profiles, how to use them, how to market yourself, how to network

LinkedIn Profile:

LinkedIn profile is the LinkedIn page that describes our career history, education, interests, and other related content which we want to publish. Many people use the word “profile” to describe their LinkedIn account.

An ideal LinkedIn Profile showcases who we are, what we do and why should we be noticed. If any employer is interested in knowing about us, they can find everything they need by having a glance at skills, projects, work experience, achievements etc., LinkedIn Profile helps us in increasing our brand.

How to use LinkedIn Profile:

Create a complete Profile. A complete profile which includes projects, work experience and skills is very important in order to use the profile effectively.

Include a Photo. A professionally taken photo should be included (headshot is recommended).

Professional Headline. The professional headline is the line that appears immediately below our name at the top of the profile. Customizing the headline shows how we stand different from others who have the same job title as ours and use similar keywords. A good headline tells others what we do and what benefit they get from working with us. It represents our core values, expertise and personal branding.

Professional Summary. This section should provide an answer to questions ‘Who we are?’ and ‘What we do?’

Include Skills.  All the skills from the resume should be included in our profile. Employers use skills as the search criteria while looking for individuals in LinkedIn. So, having skills in the profile increases our probability of being chosen.

Include Projects. Including the projects is very beneficial. Detailed description and the results of Projects might be very helpful if a random employer finds a Project interesting. Including the Github links for the project code is recommended.

Profile should be updated regularly. Whenever a new skill is learnt or a Project is accomplished or when we change company, the profile should be updated.

LinkedIn should be used for Job Search. We can search for jobs in LinkedIn using the keywords of our interest. Some examples  of keywords are Big Data Engineer, Java developer etc.,

How to market yourself using LinkedIn:

Most people only use LinkedIn as an online resume. To take LinkedIn to the next level and use it as a marketing tool, we need to put the following recommendations into action.

• Status Updates: One of the best ways to keep our connections informed about  happenings is by posting ‘status updates.’ Status updates are brief statements that we feel our connections will find useful. To appear active in the LinkedIn community, post useful status updates on a regular basis.

• Presentations: Whenever we post PowerPoint presentations to Slide Share or Google Docs, we can display them in our LinkedIn profile.

• Events: When we speak at an event or sponsor a training session, we can post a LinkedIn Event to help promote and generate interest in our event.

• Tweets: If we are an active participant in Twitter, we can integrate our LinkedIn Status Updates with the Twitter Tweets to keep our connections and followers informed.

• Polls: LinkedIn Polls are a market research tool that allows us to collect actionable data from our connections and the professional audience on LinkedIn.

• LinkedIn URL.We can use the LinkedIn URL on resumes, business cards and social networking profiles. This might help us in taking advantage from LinkedIn to market ourselves.

How to network:

Join the Groups. LinkedIn Groups can help us form new connections. Groups related to our school and groups related to our professional interests help us increase the connections and thereby improves our network.

Customize the requests when connecting. As we build connections, requests should be customized with a friendly note and, if necessary, a reminder of where we met or what organization we had in common with them.

Endorse others.  As we build connections, we must also support others. We can endorse others for their professional skills if they truly deserve it. They might endorse us in return which might strengthen our network.

Get Recommendations. Recommendations from professors, managers and colleagues are very important as they indicate our professional nature. They reflect our accomplishments, skills and experience.

Request informational interviews. We shouldn’t ask professional contacts for a job. Instead, we should ask for a brief phone conversation to seek their job search advice.

Get to know about people before the meeting. Before a formal interview, or a networking event, we should use LinkedIn’s Advanced Search and Company Pages to learn about the background and interests of the people we are meeting.

References:

[1] Retrieved from https://university.linkedin.com/content/dam/university/global/en_US/site/pdf/TipSheet_NetworkingonLinkedIn.pdf

[2] Craft a Powerful LinkedIn Professional Headline | Judy Schramm | LinkedIn. (n.d.). Retrieved from https://www.linkedin.com/today/post/article/20140508125335-96757-craft-a-powerful-linkedin-professional-headline

[3] How to Use LinkedIn as a Marketing Tool | SVM E-Marketing Solutions. (n.d.). Retrieved from http://www.svmsolutions.com/online-marketing/how-to-use-linkedin-as-a-marketing-tool/

Agile tasks lists, what does “done” mean in Agile?

In Agile methodology, user stories are one of the primary development artifacts for Scrum teams. A user story is a very high-level definition of a requirement, which the developers use to produce a reasonable estimate of the effort to implement it. The user story can be considered as the vertical slice of the system and they are broken down into tasks. A user story may (and mostly will) touch components in all of the architectural layers of the system. The tasks might be considered as the work needed to be done on each of the components that the user story touches.

How to write tasks from a user story:

For example, Let’s say we have a user story “In order to easily follow the tweets from my friends, as a registered user, I want to automatically follow all of my gmail contacts that have twitter accounts.”

In order to accomplish this, we will have to pass through the User Interface layer, service layer, persist some data in the data layer, and make an API call to twitter and gmail.

The tasks for this user story might be:

• Add the option of following gmail contacts to the menu
• Add a gmail authentication screen
• Add a twitter authentication screen
• Add a contact selection screen
• Add a controller that calls the service layer
• Implement a new service that does the work
• Save contacts to the database
• Modify the existing gmail API calling service to get contacts
• Implement a twitter API calling service to follow selected contacts

These are the possible tasks for the mentioned user story.The best practice for sizing the tasks is to allocate a day for completing it. Depending on the difficulty, we might break down these tasks further, or combine some if they are too easy. In this casethe API calling services are very easy and we can combine them to be a single task (calling external API’s).

Each of these tasks will have an estimate time along with the project member who is responsible for delivering the task. The Project status can be tracked all the time because of this and even the team members will be responsible as they are the ones who should deliver the accomplished tasks.

DONE in Agile:

In agile development, the features developed within an iteration (Sprint in Scrum), should be totally completed by the end of the Sprint. The team agrees on a list of criteria which must be met before a “user story” is considered “done”.

Misconceptions on DONE:

• DONE doesn’t mean tested.
• DONE doesn’t necessarily mean styled.
• DONE doesn’t usually mean accepted by the product owner.

What actually DONE means:

DONE means developed. In an ideal situation, each iteration or Sprint should lead to a release of the product. For a software project it is not feasible to do a release after every Sprint but completing each feature in turn enables a very precise view of progress and how far complete the overall project is. In agile development, we should make sure that each feature is fully developed, tested, styled, and accepted by the product owner. Once all of them are completed, it is then counted as DONE, which means shippable. There might be a situation where a feature may depend on the completion of other features. But every feature should be shippable on its own merit.

It is important to complete each feature before moving on to the next one. Multiple features can be developed in parallel in the case of a team. But a developer should not move to a new feature until the last one is shippable. It is important to ensure that the overall product is in a shippable state at the end of the Sprint.

References:

[1] agile – Breaking a project’s first User Story in to tasks – Stack Overflow. (n.d.). Retrieved from http://stackoverflow.com/questions/7981316/breaking-a-projects-first-user-story-in-to-tasks

[2] Agile Principle 7: Done Means DONE! | All About Agile. (n.d.). Retrieved from http://www.allaboutagile.com/agile-principle-7-done-means-done/

[3] User Stories: An Agile Introduction. (n.d.). Retrieved from http://www.agilemodeling.com/artifacts/userStory.htm

What is an Agile Sprint Retrospective?

Sprint Retrospective is a meeting that takes place in any agile-managed project. Scrum master, product owner and the development team discusses about how the sprint went and how the next sprint should be improved. Regular inputs from the stakeholders can be quite valuable and they might be helpful for the retrospective meeting.

The primary performer for the sprint retrospective is the scrum master and the secondary performers are the members from scrum team. The inputs from the sprint review meeting will be considered mandatory for sprint retrospective.

Improving the processes continuously is the main agenda of the sprint retrospective. The output of work, efficiency and work velocity will be increased by improving the processes and customizing them, as per the needs of each individual scrum team.

The main advantage with the Agile approach is that, it identifies the problems within the project very quickly. The data from the sprint backlog might be very helpful in deciding where the development team slowed down.

The Sprint Retrospective can’t take place for more than 3 hours and is mainly intended to answer three key questions:

• What went well during the sprint?
• What can be changed?
• How the change can be implemented?

Key Practices for Sprint Retrospective:

• Meeting Customer satisfaction: Sprint Retrospective can be used for making an assessment on how well the scrum team is addressing the customer satisfaction.
• Welcoming Changing requirements: Sprint Retrospective can be used to assess if the product backlog is changing and if the members of scrum team and product owner are flexible enough to keep up with the change.

• Delivering working software regularly: The results from the sprint review can be analyzed during the Sprint Retrospective. This can be used for the regular delivery of working software.
• Sprint Retrospective can be used to decide on how well the technical and business teams are working together.
• Giving support and trust: During the Sprint Retrospective, the members of scrum team can make self-assessments. An assessment can also be made on the infrastructure provided by the management.
• Delivering working software: Quality of the deliverable to date can be assessed during the Sprint Retrospective.
• If there are any negative indications about the project sustainability, then they should be discussed in this meeting.
• If there are any unnecessary things which make the system complex, then those should be discussed in the meeting.
• If there are any evidences that the scrum team is hindered because of the lack of self- management, then those issues should be discussed in meeting.

To summarize, sprint retrospective is the reflection of regular activity that is taking place.

References:

[1] Agile Management and the Sprint Retrospective (- For Dummies) http://www.dummies.com/how-to/content/agile-management-and-the-sprint-retrospective.html

[2] Sprint Retrospective – Scrum Project Management. (n.d.). Retrieved September 28, 2014, from https://sites.google.com/site/agiledevelopmentsite/process/sprint-retrospective

[3] Five steps to an effective sprint retrospective. (n.d.). Retrieved September 28, 2014, from http://leadingagileteams.com/2014/07/13/5-steps-to-an-effective-sprint-retrospective/

The Agile Team and Backlogs

Agile Team:

The Agile teams have several roles, which have different names based on the methodology being adopted. A person in an Agile Team can take one or more roles and even can switch roles over time. Here are common agile roles:

Team Lead:

In an Agile Team, this role is responsible for acquiring resources for a team, facilitating the team members and protecting the team from problems. This role has different names in different methodologies. In Scrum methodology, this role is called ‘Scrum Master’. In other methodologies, this can be called as a team coach or a project lead. This role doesn’t deal with the technical stuff like project planning and scheduling, but deals with the soft skills of project management.

Team Member:

The duties of this role include architectural design, data modeling, development, testing, release activities and many other activities which are required for the creation and delivery of the system. This role can also be referred to as developer or tester.

Product owner:

The product owner is responsible for prioritizing the work item list, which would help the team in making timely decisions.  This would also help the team in obtaining the information at the right time in a timely manner. The product owner is called on-site customer in XP(an Agile methodology).

Stakeholder:

A stakeholder can be a direct user, indirect user, help desk member, auditor, maintenance professional, senior manager, developers working on other system which is to be integrated with the one currently under development, operations staff member. To summarize, any person who is affected by the development and deployment of a project can be called a stakeholder.

Backlog:

A list of features or technical tasks are required to complete a project or a release. A backlog consists of such features or technical tasks which the team should maintain in order to complete a project or a release. The features which do not contribute to the project’s goal are to be removed. In the same way, if at any time a new feature seems to be necessary for the project, it should be considered and added to the backlog.

A backlog can be considered as the primary point of entry for the details on project requirements. As the team gains knowledge, a backlog is expected to change throughout the project’s life cycle.

A product backlog is a list of all desired product features. It can contain business and technical requirements, ideas for future enhancements, bugs and non-functional items.

The Sprint backlog is a deliverable created as a subset of the Product Backlog. It is a to-do list of backlog items to be completed in the current iteration.

Common Pitfalls:

• A backlog should not be misconstrued with a ‘requirements document’.
• A backlog can be of any format. It can be a spread sheet, a text file, a database or a collection of index cards.
• A backlog avoids the risk of creating multiple versions, as its main agenda is to maintain a single trusted source, which should be used during the project development.

References:

[1] Roles on Agile Teams: From Small to Large Teams. (n.d.). Retrieved September 21, 2014, from http://www.ambysoft.com/essays/agileRoles.html

[2] Backlog. (n.d.). Retrieved September 21, 2014, from http://guide.agilealliance.org/guide/backlog.html

[3] E.Moreira, M., Lester, M., & Holzner, S. (n.d.). Agile for Dummies. Ca Technologies Edition.   

[4] Product Backlog VS Sprint Backlog. (n.d.). Retrieved from http://www.theitba.com/product-backlog-vs-sprint-backlog/

What is Agile and what are user stories?

Agile:

• Agile software development model comprises of a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing and cross-functional teams.
• Agile model promotes early delivery, continuous improvement and encourages rapid and flexible response to change.
• Agile model focuses on delivering small increments of working software.

Agile gives importance to:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over following a plan

• Individuals and interactions: In agile methodology, self-organization and motivation are important.
• Working software: Working software is more helpful to clients than just presenting documents.
• Customer collaboration: All the requirements cannot be collected at the beginning of the software development cycle. Hence, continuous client or stakeholder involvement is mandatory.
• Responding to change: Agile methodology mainly focuses on response to change and continuous development.

Agile Vs. Traditional Methodologies:

The modern software development life cycle methodology can be divided into Traditional process and Agile process.

Traditional methodologies follow a sequential series of steps like requirement definition, planning, building, testing and deployment. The client requirements are gathered first and documented, then the general architecture is designed, after which the coding commences. Different kinds of testing are done and then the final product is deployed. The main agenda here is the detailed visualization of the finished project before the development is started.

Agile is incremental and iterative development model. In Agile, software is not treated as a large block of a structure, but an entity with complex parts interacting with each other. Agile methodology mainly focuses on response to change and continuous development.

The differences are explained with respect to different attributes:

Customer Involvement: Traditional methodologies require the user to provide a detailed idea of the exact requirements. The agile developers are more flexible because of their iterative style of development. In agile model, the user is constantly in the loop providing improvements and reviewing every phase as well.

Cost: The reworking costs are very low in agile computing when compared to the traditional methods. The end product of every phase is completely tested, because of which the changes in the requirements are accommodated easily.

Flexibility: In traditional systems, the role of a coder and a business analyst is bifurcated. In traditional systems, the requirements are collected, analyzed by the business analysts and then developed by the coders. In agile, the customer interaction is extensive at every phase of development. This is the reason because of which, the flexibility involved in architectural and functional phases is high.

Documentation: Traditional methodologies tend to produce documentation, before any production code is written.  Such documents may include various types of requirement documents like Stakeholder needs, Product Requirement Documents, Business Requirements Documents and Software Requirement Documents. These documents may also include Sequence Diagrams, Communication Diagrams, Entity Relation Diagrams etc. Agile projects avoid large documentation at the beginning of the project, as agile projects focus on implementing and delivering working functionality, rather than writing traditional requirements and design documents from the very beginning of the project.

System Size: In Agile methodology, small to medium sized systems are perfect, as they offer more flexibility. The large size teams should either adapt traditional methods or should split the team into smaller ones and then should apply agile methodologies on those small teams.

User Stories:

• User stories are the primary development artifacts for Scrum and Extreme Programming (XP) project teams. It is a very high-level definition of a requirement. It contains sufficient information using which the developers can produce a reasonable estimate to implement it.
• A user story is necessary to have a conversation with the customer, which can also be treated as a reminder to do just-in-time analysis. User stories are very high level requirements artifacts.

Important considerations for writing user stories:

Stakeholders write user stories. The user stories are written by stakeholders, not by the developers. User stories should be simple enough that people can learn to write them in a few minutes.

Use the simplest tool. User stories are often written on index cards. It is very easy to work with Index cards.

References:

[1] Agile software development. (n.d.). Retrieved September 14, 2014, from http://en.wikipedia.org/wiki/Agile_software_development

[2] Traditional Vs Agile Software Development – Optimus Information Inc. (n.d.). Retrieved September 14, 2014, from http://www.optimusinfo.com/blog/2014/02/04/traditional-vs-agile-software-development.html

[3] Traditional vs. Agile Documentation -. (n.d.). Retrieved September 14, 2014, from http://www.blue-agility.com/traditional-vs-agile-documentation/

[4] User Stories: An Agile Introduction. (n.d.). Retrieved September 14, 2014, from http://www.agilemodeling.com/artifacts/userStory.htm