Category: Scrum

Always pushing to improve - the Sprint Retrospective Meeting

6/29/2015

No matter how good a Scrum team is, the opportunity to improve is constant. This is the overarching purpose of the Sprint Retrospective Meeting – encouraging the entire team to build on their success and address any potential challenges or issues and grow as a team.

The Sprint Retrospective is usually the last thing done in a sprint and many teams will complete the meeting immediately following the Sprint Review. The entire team, including both the Scrum Master and the Product Owner should participate. Retrospectives are usually scheduled for up to an hour but allow time for any hot topics or team conflicts that may arise as a result of this meeting.

The environment for Sprint Retrospectives must be safe for everyone. This means attendees must be transparent while treating others with respect. This is not an opportunity for personal criticism or attack.

While Scrum says little about the internal structure of Sprint Retrospectives, it does specify that the output of the Sprint Retrospective is any improvements the team will perform for the next Sprint. Productive Sprint Retrospectives share the following characteristics:

The entire team is engaged
Discussion focuses on the team rather than individuals
The team’s Definition of Done is visited and hopefully expanded
A list of actionable commitments is created
The results of the previous Sprint Retrospective are visited
The discussion is relevant for all attendees

In many respects, these meetings are the most effective and action-oriented form of a review meeting but they can be tricky to run in the right way. The Scrum Master can facilitate this sprint retrospective meeting by asking everyone to just shout out ideas during the scrum. Or, for example, he or she can tell everyone to focus on identifying something to stop this time because not much attention has been paid to things to stop in recent retrospectives. After an initial list of ideas has been brainstormed, teams will commonly vote on specific items to focus on during the coming sprint.

Learn more about the Sprint Retrospective Meeting and why it is considered by many to be the life-blood of a development team. Courtesy of agilemethodology.org, this video series takes you through the life-cycle of a Sprint, from planning through to retrospective. Link to Video 6 - Sprint Retrospective Meeting here.

3 Comments

Inspect and Adapt | The Sprint Review Meeting

6/24/2015

3 Comments

Did we do what we set out to accomplish during our sprint? Do we have a coded, tested and usable piece of software ready for the product owner?

These are just some of the questions asked during the Sprint Review Meeting. On the last day of the sprint, the team meets with the product owner, customers, and stakeholders to accept completed work and to identify new requirements. After this meeting the team plans the next sprint. In this way, the development team receives the feedback they need to move forward in the design process and provides a stronger and more functional software product.

You may be asking, “well, isn’t this just the same as the Daily Scrum Meeting but with a different name?” The short answer is “no”. One of the guiding principles of Agile is to continually improve and constantly communicate. Reviewing what has been accomplished during the active Sprint is a critical piece to ensuring that the product owner sees what the team has completed. And, in many cases, your customers will understand their additional needs more fully after seeing the demonstrations and will identify and discuss the changes that they want to see.

There will be many times where the product owner will understand additional needs more fully after seeing the demonstrations and will identify and discuss the changes that they want to see. As well, you can take advantage of this time to review any backlog stories and see if priorities have changed.

Here’s a sample agenda for the Sprint Review Meeting. Of course, your team may wish to modify it based on your needs.

Agenda

- Product Owner identifies what has and has not been done
- The Development Team talks about the Sprint and discusses:

What went well
Problems that came up
How the team solved those problems

- The Development Team demonstrates completed work and discussed product backlog items
- Product Owner discusses current backlog and plans completion dates with various completion rate assumptions
- All attendees discuss previous agenda items and how they could affect what to do next
- All attendees provide vital input into Sprint Retrospective Meeting or next Sprint Planning Meeting

Courtesy of agilemethodology.org, this video series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 5 - Sprint Review Meeting - and be on the lookout for more videos in this series over the next few weeks.

P.S. Let us know what you think.

3 Comments

Three questions to development success - the daily scrum meeting

6/19/2015

1 Comment

Wouldn't it be great if every morning you started off asking yourself three questions:

What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?

These three questions help to prepare and provide a guideline for your day. This is exactly what a Scrum or "stand-up meeting" accomplishes. These short meetings keep the development team on track to accomplish the goals agreed on during the Sprint Planning Meeting.

Usually taking place at the same time and place every working day, scrum meetings also promote closer working relationships between team members, which, in turn, creates a better product for the customer.

While there are a lot (and we mean a lot) of examples out there on how to best conduct a daily coordination meeting, the best advice we can give is to find the outline and platform that works best for you and your team. Sometimes, just a quick 15-minute meeting every morning is enough to get the juices flowing as it were for the day. Sometimes, you’ll have to pass around a token for the person speaking to hold and limit their time. And sometimes, you’ll actually need to have your team stand. Use whatever works for you just as long as you follow the three questions of the meeting:

What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?

Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 4 – Daily Scrum Meeting - and be on the lookout for more videos in this series over the next few weeks.

1 Comment

Coordinated planning = project success

6/16/2015

3 Comments

When you’re working within the agile development process, the team’s goals and tasks are accomplished within a “sprint” framework. Simply put, a “sprint” is a designated amount of time – usually two weeks – where your team decides together what will be completed during that time. On the first day of each sprint — often a Monday morning — the scrum team holds the sprint planning meeting.

Very much a collaborative effort, the Product Owner describes the highest ordered product backlog items then the team determines and prioritizes what is necessary to complete those particular tasks. Team members volunteer to own the work and work owners estimate the ideal hours they need to finish.

Sprint Planning Meetings are made up of two different parts. Part 1 focuses on what the team is being asked to build and is attended by both the product owner and the team. Part 2 focuses on how the team plans to build the desired functionality. And, although the entire team must attend Part 2, attendance by the product owner is optional.

In Part 1, the product owner has the opportunity to describe a desired set of “stories” to the team. This is a deep-dive session on what the product owner would like to see developed. The product owner presents the stories, shows how things interact and walks through the interface. Additionally they may review infrastructure or architectural items. The goal is to inform the team with as much information as possible so they can determine how to best build the functionality. Types of questions typically asked include:

“What is the acceptance criterion of all of these stories?”
“What data sources do you think we are using?”
“How should the interface look on this component?”
“What are you expecting from the user experience?”

During Part 2 the team then turns its attention to building the “sprint backlog”. This is the list of stories and the tasks required to complete them during the sprint. To build the backlog, the team breaks down each story that the product owner has requested to the task level and then each task is given an hourly estimate. By the end of Part 2, the team decides which stories it can commit to completing during the sprint. Together, the two parts of the sprint planning meeting can take anywhere from two to eight hours.

Accomplishing what you set out to do

As long as the team leaves the Sprint Planning Meeting committed to completing a list of stories, the team has accomplished what they set out to do. Getting the team to the point where each team member feels comfortable making that commitment, however, requires a bit of pre-planning and facilitation.

The product owner must come to the meeting able to describe a set of desired stories. The team’s objective, then, is to understand the stories from the product owner’s point of view and share in the product owner’s vision. The ScrumMaster should ensure that the team is asking enough questions and capturing all of the resulting data, including acceptance criteria, sketches, and any assumptions. The ScrumMaster should also let the product owner know that the team might have additional questions after it begins to break the questions down into tasks. And finally, although the product owner presents stories s/he believe the team can complete within a given sprint, the development team will ultimately decide whether it can, in fact, take on all of the stories based on what it learns during Part 1 and Part 2 of the sprint planning meeting.

Here’s a sample Sprint Planning Meeting agenda

Product Vision and Roadmap [Product Owner]
Development status, state of our architecture, results of previous iterations [Team members]
Iteration name and theme [ScrumMaster]
Velocity in previous iteration(s) [ScrumMaster]
Iteration timebox (dates, working days) [ScrumMaster]
Team capacity (availability) [Team members]
Issues and concerns? [ScrumMaster]
Review and update definition of Done [Team members]
Stories/items from the backlog to consider [Product Owner]
Tasking out [Agile Team]
Issues, Dependencies and Assumptions [ScrumMaster]
Commit! [Agile Team]

Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 3 - Sprint Planning Meeting - and be on the lookout for more videos in this series over the next few weeks

3 Comments

A little trimming never hurt anyone... backlog refinement

6/11/2015

3 Comments

We've all seen overgrown gardens; plants that have grown in all directions and are completely unmanageable. A little bit of trimming here, removing dead leaves there and you now have healthy plants. It's the same principle in Agile software development with "backlog refinement".

Backlog refinement is a core planning activity in Scrum and is an on-going activity throughout the project to constantly improve the process and ultimately output a better product. Most projects will have a product backlog (that which is wanted but not a priority during a sprint). Product backlogs are constant and ever changing as new ideas flow in, existing product needs are refined, new discoveries are made, and priorities and business need change throughout the project timeframe.

So how do you successfully refine project backlog? Here are a few tips to get you started:

Prioritize, prioritize, prioritize. Everyone wants everything in their project. If you follow a few items, such as customer and business value, along with improving the quality of the project, you’ll be well on your way.
Examine stories frequently. The great thing about Agile development is that it can change based on your priorities. Never again must development teams wait until the very end to see if what they’ve developed is right. The trick is to scrutinize stories to ensure they are getting you the best result.
Schedule refinement meetings frequently. This keeps the entire team engaged on what should be occurring and what could occur (see #1).
Refining is planning. If you refine what you are doing, chances are, you’ll get to your successful end goal quicker.
Never cancel refinement. Ever. Seriously. The team has to be able to refine their priorities (see #1) to ensure that the best product / project is produced. One expert suggests that if you find your spring planning meetings lasting longer and longer, you’ve probably been under-refining. However, if you are doing enough refining, your sprint planning meetings should be effective, focused and short.

We take backlog refinement one step further and work with you to take care of the product by removing unwanted features and defects and other items that are no longer necessary. This ensures that that only valuable features are prioritized and move forward.

Link to video 2 here. Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Let us know what you think about backlog refinement in the comments below.

3 Comments

Best practices in agile development - blog series

6/9/2015

1 Comment

At Latitude 40, we develop your custom software development projects using the agile development methodology. This is very different from traditional development approaches where you must wait until the end to view the completed software project. Agile empowers you to be involved in the development process from day one. The benefit is that projects are completed more efficiently and with better quality than traditional methods of developing software.

Because we use this method of software development, we thought we'd bring you a series of videos through our blog that take you through the stages of the Agile process. Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 1 and stay tuned for more videos in this series over the coming weeks.

I also want to hear from you; your thoughts and musings on Agile. Let me know what you think.

1 Comment

Latitude 40 blog

Always pushing to improve - the Sprint Retrospective Meeting

Inspect and Adapt | The Sprint Review Meeting

Three questions to development success - the daily scrum meeting

Coordinated planning = project success

A little trimming never hurt anyone... backlog refinement

Best practices in agile development - blog series

Author

Archives

Categories