What is Agile Sprint Retrospective ?

Looking back into the past is a great way to learn the lessons and make further adjustments so that we can have a smoother future. In Agile methodology , after the completion of every iteration , the team has the opportunity to look back on the iteration and take the learning’s from that iteration into the next iteration.This planned opportunity is called ” Sprint Retrospective” or “Iteration Retrospective“. It is generally conducted at the end of the sprint. The output of the sprint retrospective will help in planning for a  next smoother iteration.This method enables the agile team to continuously improve as the project progresses

sprint_loop_events

Typically a retrospective meeting starts by checking the status of the actions from the previous retrospective to see if they are finished, and to take action if they are not finished and still needed. The actions coming out of a retrospective are communicated and performed in the next iteration.

To ensure that actions from a retrospective are done they can for instance be added to the product backlog as user stories, brought into the planning game and put on the planning board so that they remain visible to the team.

How did we plan ?(Linders,2013,para 3)

During the Iteration planning , we planned for a meeting for about 45 minutes with the whole team at the end of that iteration.The scrum master has to arrange and plan for this meeting and invite the entire team including the Product Owner, Developers, Testers, User Interface Engineers and anyone directly involved.All team members attend the retrospective meeting where they “inspect” how the iteration has gone and decide what to improve and how they want to “adapt” their way of working and behavior.

The following are the four Key Questions that a scrum master asks in a retrospective

  1. What did we do well, that if we don’t discuss we might forget?
  2. What did we learn?
  3. What should we do differently next time?
  4. What still puzzles us?

The Scrum master notes it on a white board as below:

rett

Additional topics can be open for discussion like(Layton ,2010,para 6)

  • Results: Compare the amount of work planned with what the development team actually completed. Review the sprint burn down chart and what it tells the development team about how they’re working.

  • People: Discuss team composition and alignment.

  • Relationships: Talk about communication, collaboration, and working in pairs.

  • Processes: Go over getting support, development, and code review processes.

  • Tools: How are the different tools working for the scrum team? Think about the artifacts, electronic tools, communication tools, and technical tools.

  • Productivity: How can the team improve productivity and get the most work done within the next sprint?

5 step plan for successful retrospectives : ( Burson,2013, para 8)

Most of the industry is in agreement and has adopted this strategy. The 5 steps are:

1. Set the Stage

2. Gather Data

3. Generate Insights

4. Decide What to Do

5. Close the Retrospective

Retrospectives are a great way for teams to improve their way of working, to become more agile and lean. Getting actions out of a retrospective that are doable, and getting them done helps teams to learn and improve continuously.

What i learnt from the Sprint Retrospective of our project 

Retrospection is always a great way to learn from your mistakes and not to repeat them again. We have always faced so many problems when it comes to communicating with the client , getting details from them and putting all of it into actions. Our client was not so responsive and we had to struggle in the beginning to gather the requirements. Over the sprints , we have learnt from our mistakes and started to work on a prototype until we waited to communicate with the client. Instead of waiting for them we discovered a new way by working on the prototype and once we got a chance to communicate with client ,we gathered all the requirements and put our prototype into the real implementation and succeeded in doing our work in time.

References :

  1. Linders.B.(203,March 11).Which questions do you ask in retrospectives?. Bin Linders Sharing my experience.Retrieved from http://www.benlinders.com/2013/which-questions-do-you-ask-in-retrospectives/
  2. Layton.C.M.Agile management and sprint retrospective.For Dummies – Making everything easier . Retrieved from http://www.dummies.com/how-to/content/agile-management-and-the-sprint-retrospective.html
  3. Burson.K.(2013,January 17).Effective retrospectives. CPrime. Retrieved from https://www.cprime.com/2013/01/effective-retrospectives/
Advertisements

Agile Team and what is a Backlog ? Why are the backlogs for and why are they important

AGILE TEAM

In a Agile project , the people take one or more roles and he or she can also change their roles over the period of time.Agile considers all the team members as equal and everyone works to deliver the project regardless of their role. The following are the important roles which every agile team comprises of (Ambler & Holitza,2012,page 8)

1. Stake holder : A Stake holder is the person who is financially impacted by the outcome of the solution and can be a senior manager , an auditor , a program manager or even a IT staff member.

2. Product Owner : A Product owner is the person who represents the needs of the stakeholder community to the agile team.He develops strategy for the project and manages product requirements.

3. The Business owner who communicates with the stakeholders , the product owner and the scrum team members.

4. Scrum master is the person who manages the scrum team and takes requirements and other details from the business owner.

Apart from the above mentioned team members the other important team members include the Domain expert , specialist , technical expert ,  testers and integrator. The following figure best describes the team members of an agile team

a468-f1-scrum-team2

The two important characteristics of a great agile team are that they are stable and cross functional.

WHAT IS A BACKLOG ? (“Scrums Product Backlog” , Para 6)

“The product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made in the product” 

The term ” product backlog comes from the agile method ‘Scrum’. In simple terms a product backlog is a prioritized features list containing short descriptions of all functionality desired in the product.The product backlog is managed by a person with the ability to understand the business needs. It is typically used to

  • capture requests for modifying a product.  This can include add new features, replacing old features, removing features and fixing issues; and
  • ensure the delivery team is given work which maximizes the business benefit to the owner of the product

The product backlog consists of :

  • user stories – representing new functionality; and
  • bugs – representing work to address a defect.
  • Technical work
  • Knowledge acquisition

If an item on the backlog doesn’t contribute to the success of project’s goal , then it must be removed and if any feature or a task is considered important for the project , it should be added to the backlog . The backlog is not a requirement’s document.

WHY IS A BACKLOG IMPORTANT AND WHAT ARE THEY FOR ?

The features of a product are listed in the backlog and the items in a backlog are completed in series of sprints. If later if any requirement comes up , it can be accommodated in the backlog. The following figure briefs that :

BacklogFeedbackLearning

The product backlog  is made to be visible to everyone so that everyone can know what is going on and places high emphasis on Collaboration and surprises. It is a single source and copy of truth .It’s important for the source of requests to be centralized because the entire list needs to be ordered.A single copy is needed because we want to avoid multiple people updating the backlog at the same time, with the consequence that those updates conflict. Resolving conflicting updates can be difficult.It’s dynamic nature allows the requirements and features to be added at the later stages too.

backk

The product backlog is important because it provides the following features for the project. The terms DEEP and INVEST are coined to explain its importance :

How backlogs played an important role in our project : (Wikstrand,2010,para 4).

The product backlogs are important for any agile project and this is how the backlogs helped us

Our backlog was Detailed Appropriately , Emergent in nature, Estimated delivery time and Prioritized items are clearly mentioned which helped us to refer to them and proceed in the right direction.

  • In our project we developed the backlog item independently, otherwise we couldn’t have moved it around in the time.
  • The whole team was responsible for negotiating  the specifics of the backlog item with the customer. This affected the schedule as one of the things that can be negotiated with the customer is the scope and any further breakdown of the item.
  • Our backlog was divided based on a user perspective, not a systems perspective. For example : We have incorporated specifications in backlog which is achievable by users and not purely based on system.
  • Our backlog items are estimated and used them to schedule our project.
  • Our backlog items are small enough to fit several of them in one iteration.
  • It was possible to know when we are done with our backlog item by testing it. This affects the schedule as it defines when an item is done.

invest

These features of product backlog make the agile process and the projects to be successful.

Reference :

  1. Mansour.M.Scrum’s product backlog – Agile requirements management.Agile Bench. Retrieved from http://agilebench.com/blog/the-product-backlog-for-agile-teams
  2. Wikstrand.G.(2010,October 25).Agile requirements and the agile backlog. Retrieved from http://www.gregerwikstrand.com/blog/requirements-and-backlogs/
  3. Scwaber .Kand Beedle.M.(2002).Agile software development with SCRUM. p33. Prentice Hall.
    1. Ambler,S.W. & Holitza,Matthew.(2012) Agile for Dummies,IBM limited Edition.New Jersey,NJ: Wiley.

What is Agile and What are User Stories

What is Agile ?

Agile is one of the biggest IT buzz words today. Putting it in simpler words , Agile is a methodology for software development process which follows a incremental approach.Agile methodology has become more popular and success than any other software development methodology today.To understand why agile has become very popular we have to understand other old software development methodologies. One of the first among those software development methodologies are (Ambler & Holitza,2012,page 4)

  • Code-and-fix/Big Bang development : In this method the code was written and then later fixed the bugs as they were found.The software was all delivered at once and it became more complicated as the amount the of the code grew
  • Waterfall : To overcome the problems of Code-and-fix model , the waterfall model has come up with specific stages as Requirements ,design , development , integration , testing and deployment.This is a sequential process and going back to the previous stage is not possible and the software development process has to started all over again . One of its problems are its risky to implement a waterfall model for a long project which business needs change . Its limited flexibility and reduced customer involvement makes it not so preferred methodology for  software development process.
  • The Spiral model : The Spiral model is both incremental and iterative and this archetype followed something closer to the Waterfall model

In February of 2001 , a group of developers developed a lightweight development methodology which is known as agile.

The Agile Manifesto :

The Agile manifesto can be better understood from the following figure which simply stresses four values :

agilemanifesto

We implemented the following principles in our project : (“Principles Behind the”,2001).

1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective and then tunes and adjusts its behavior accordingly.

The main participants or the roles under the agile methodology are Stakeholder , Product Owner ,Team member, Team lead, Architecture Owner, Agile mentor.

Agile Planning :

Five levels of Agile planning can be described and understood as below :

agile five levels of planning

Now lets try to understand about Creating user Stories :

A user story is a simple description of a product requirement in terms of  what that requirement must accomplish for whom. Your user story needs to have, at a minimum, the following parts:(Layton ,2010,para 2).
Title: <a name for the user story>
As a <user or persona>
I want to <take this action>
So that <I get this benefit>

A very simple example of an agile story is ” As a  mom , I want to take and share pictures and videos of my kids so that i can share important moments with grandparents, aunts , uncles & other friends. Where as a typical user story for a software design might look like this :(Ewel,2011,para 3).

user-story31

The above example best describes what a user story is . Good user stories can also be used for writing test documentation and user documentation.

References :

  1. Jalali,S.Wohlin,C.(2010).Agile Practices in Global Software Engineering – A Systematic Map. International Conference on Global Software Engineering (ICGSE). New Jersey,NJ: Princeton.
  2. Ewel,J.(2011,November 16).User stories in agile marketing Part 2.Agile Marketing. Retrieved from http://www.agilemarketing.net/user-stories-agile-marketing-part-2/
  3. Writing user stories for agile projects. (2009,20 May).Breathingtech.com. Retrieved from http://breathingtech.com/2009/writing-user-stories-for-agile-scrum-projects/
  4. Principles behind the agile manifesto.(2001). Retrieved from http://agilemanifesto.org/principles.html
  5. Layton,M.C.(2010).The four components of an agile user story.Retrieved from http://www.dummies.com/how-to/content/the-four-components-of-an-agile-user-story.html
  6. Ambler,S.W. & Holitza,Matthew.(2012) Agile for Dummies,IBM limited Edition.New Jersey,NJ: Wiley.