Resolutions, Reviews and Retrospectives

Resolutions, Reviews and Retrospectives

As a matter of course, I don’t make New Year’s Resolutions until at least February and this year, I have not made any.

Since I am a Scrum Master striving to lead an Agile Life, I’ve started planning and living my life in 2 week iteration (sprints) and am doing my first Sprint Review and Retrospective today. It is so much easier to set and achieve goals in a short 2-3 week period rather than the whole year. Plus it makes me very happy and excited to move my yellow sticky note user stories from the “In Progress” to the “Done” column (I know I am a total geek. See my article on Confessions of a Dashboard Junkie for further proof).

It is satisfying to have rapid feedback and visualization on the completion of your small, bite-sized chunk goals (user stories) and it is important to do a thorough review of the Sprint Board at the end of each iteration to determine what is still In Progress and/or what is not started in the To Do column.

Sprint16.1start

Sprint16.1end

 

 

 

 

 

 

 

In the Retrospective, you can reflect on what you were able to complete and why, as well as what prevented you from starting or finishing a user story. Were there obstacles or unforeseen circumstances that interfered with you completing all your goals or did you simply procrastinate? Be brutally honest with yourself and strive to improve your process in the next sprint which starts tomorrow.

MIRROR02_a

The outcome of your Retrospective is a mini New Sprint Resolution and provides input to your next Sprint Plan.  This is why I don’t need New Year’s Resolutions anymore!

The Sprint Plan is done on the 1st day of the sprint and includes all of the user stories (goals) you want to complete in the next time period. It is meant to be a realistic picture of what you commit to getting done based on your understanding of the size and scope of the various items.

Living an Agile Life is rewarding, effective and less stressful than making huge blanket resolutions on some arbitrary date at the beginning of the year. Besides, your goals for the time period of Jan. 1-15 will probably be very different than your goals for Sep. 15-30. Conducting your Reviews and Retrospectives every 2 weeks will help you quickly analyze and adjust your life plans and goals as needed plus you will get so much more accomplished than if you didn’t track and plan with your Sprint board.

So here’s a toast to happy and healthy Sprint Reviews and Retrospectives!

May the Agile force be with you.

sprint1

Advertisements

Rebooting My Agile Life

In October 2013, I wrote the following in Part 1 of my blog’s “An Agile Life” series:

“What if we lived our lives in 2 week increments?

Imagine what it would be like to create a Backlog of all the things you wanted or needed to do in your life including all of your wishes and desires. Kind of like a Bucket list on steroids.

What if you reviewed, prioritized and ordered this list every 2 weeks?

What if you planned out which items on your list (User Stories) you wanted or needed to accomplish in the next 2 week time period (Sprint)?

What if you (and your team/partner/family) committed to completing these items by the end of the Sprint? “

Well, 2+ years later and after a serious New Years Day Retrospective, it is time for a major reboot in my life sprints. Time to create my Backlog again, prioritize my User Stories and work on them in shorter iterations.

Time to post my sprint board on the refrigerator!

DSC_1963

Here we go, Day 1 of Sprint 16.01, I’ll let you know how my Retrospective went in early February!

Here’s how you can get started on your Agile Life:

Step 1: Grab some sticky notes and markers and start writing out the items you wish to work on/ accomplish (one per note).

Step 2: Create your sprint board with a sheet of page. Make 3 columns: To Do, In Progress and Done.

Step 3: Determine your sprint duration ( 1, 2, 3 or 4 weeks)

Step 4: Place your items ( user stories on sticky notes) on your sprint board.

Step 5: Review your user story status and track progress each day until the end of the sprint.

Step 6: Conduct a Retrospective on the last day of the sprint.

Step 7: Update your sprint board during for the next sprint’s planning session.

Step 8: Repeat steps 4- 6.

Good luck and may the force be with you!

agile

 

 

Confessions of a Scrum Master, Part 3: User Story Happiness & Success

As a user story, I want the respect I deserve so that I don’t develop an inferiority complex.

Oh the user story! You either love it or you hate it. You understand it or you are totally perplexed and frustrated by it. The must fundamental and core element of the Agile process is often misunderstood, under appreciated and misused.

The User Story, child of the Epic and parent to the Task, occasionally suffers from an identity crisis. Last month I happened upon a sad and lonely 8-point story who had only one 0.5 hour task linked to it. It confided in me that it was really a Task masquerading as a User Story but it was too ashamed to tell anyone.

The role and purpose of the user story can sometimes be misunderstood to the point of causing heated conversations and disagreements among Product Owners, Business Analysts and Scrum team members who are new to the Agile process. Here the Scrum Master’s coaching and facilitation of the Agile process is critical to the success and happiness of the team (and the user story).

As a user story, I want to define an incremental unit of work in the “who, what and why” format so that the scrum team can efficiently deliver the requirements by the end of the sprint.

whowhatwhy_userstory

 

As a user story, I want to represent a small piece of business value so that the Product Owner can see the iterative development of the work.

As a user story, I want to describe high-level requirements in such a way that  it sparks conversations among the scrum team members.

As a user story, I want to have detailed acceptance criteria so that the team knows the definition of done and exactly what is expected at the end of the sprint.

As a user story, I want to be groomed and refined on a regular basis so that I will be properly understood, stack ranked and sized by the scrum team.

As a user story, I want to meet the criteria of Bill Wake’s INVEST acronym so that I can be well formed and have high self-esteem.

INVESTuserstory2

Acceptance Criteria of this INVEST story:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Scalable (small sized)
  • Testable

 

As the author of this blog,  I want to share my thoughts and insights about user stories so that you learn in a fun and memorable way!

Confessions of a Scrum Master, Part 2: The Requirements Challenge

Alternate title:  Oh the joys of documenting requirements on a new Agile project!

Many organizations struggle with adopting Agile since it requires such a fundamental and overarching shift in business process.  Often times the biggest challenge with the new process is how to gather and document Requirements.   I’ve observed that a piece meal approach to implementing Agile is not as effective since the performance benefits are not fully realized unless all Scrum team members and stakeholders are on board. So how do we get everyone on board?

First, it can be helpful for Scrum Masters to recognize that the Agile manifesto value of “Working Software over Comprehensive Document” is a struggle for many Project Management Offices ( PMO) and Business Analysts (BA). Organizations and firms which are heavily regulated have strict requirements on detailed project artifacts in order to pass audits and the PMOs and BAs are oftentimes the creators and/or keepers of these documents. In short, it’s a balancing act to the find the appropriate and agreed to level of documentation that meets everyone’s needs. These discussions and agreements can take place during Sprint 0 and reviewed in the Release Planning meeting.

UnicycleSDBC2004

 

Waterfall/RUP documentation habits die hard with some seasoned BAs. The urge to analyze, research and detail out full use cases and system requirements prior to the start of sprinting can be strong for those who are new to iterative development and User Stories.   The Scrum Master’s coaching and guidance on the Agile best practices for User Story creation and refinement are critical to keeping the project moving along and not getting bogged down in analysis paralysis.

And then is there is the battle of what tools to use to document and where to store the project and requirement artifacts. Boy can opinions and passions run hot in this area!   Whether you use TFS, Rally, Jira, VersionOne, PivotalTracker or any other application for tracking your User Stories, sprint tasks and velocity, your Scrum team and the Project stakeholders need to understand and come to an agreement that certain Requirement Documents of Record can should be stored, tracked and linked to in other repositories like Sharepoint or Blueprint.   Traceability is a key concern for many organizations and should be addressed in your Team Agreements and processes.

The Goldilocks Dilemma

How much detail do we need to put in a User Story? This is another deeply philosophical question and everyone seems to have a different opinion on it.

How much is too much? How much is too little?   What level of information and detail is just right?

 

3bowlsv3

As Scrum Masters, our role is to strike the right balance with the Product Owners, BAs and PMs so that the needs of the organization are met without sacrificing the benefits of the iterative design and development. This is certainly easier said than done but know that you are not alone in this challenge.

It helps to explain that details on the requirements will be uncovered and documented in a more collaborative manner with ongoing conversions and meetings with the entire team. Requirements will not be created in a vacuum and will be refined /groomed/ sized by the scrum team.

It occurs to me that this topic is important and meaty enough to deserve its own article, so I’ll dive into the details of User Story Creation in Part 3 of my “Confessions of a Scrum Master” series next week.

The behavioral changes involved in adopting the Agile can be uncomfortable and difficult for many people and teams. Documenting requirements in Agile often requires a significant shift in process and the Scrum Master’s coaching and facilitation role is critical to helping the team to learn and understand the value and benefits of iterative development while allaying their fears and concerns about the “new and different” way.

 

 

 

 

 

Confessions of a Scrum Master

Every thing I needed to know about being a good Scrum Master I learned from my high school soccer coach, Miss Lonegan.

Slide1

Here’s what was instilled in me on a muddy soccer field in the early 1980s.

Great coaches and leaders:

  1. Motivate and help the team to be successful.
  2.  Walk with the team, on the field, everyday.
  3.  Teach others the process by sharing fundamental tasks and techniques.
  4.  Guide the team without being overly controlling.
  5.  Communicate positively.

These successful actions and traits recently dawned on me when I realized how important Personality and Temperament are to being an effective Scrum Master.

Over the past 5 years, I have been observing team dynamics as a Scrum Master (SM) on multiple teams in 3 different companies and have witnessed a number of SMs crash and burn due to not leading like good coaches. Lack of communication and soft skills were also a common theme with the ineffective Scrum Masters.

The most successful SMs are true team players and are comfortable surrendering control to the Product Owner and team. Adept Scrum Masters truly view their role as being in service to the team, removing obstacles for the team and helping them to be successful.

Facilitation is another important role of the Scrum Master and requires a high level collaboration and strong, tactful communication skills.   The authoritative, directive, ” my way or the highway ” approach does not work well with Scrum teams.

Project Managers can sometimes get away with a lack of soft skills but Scrum Masters, who are facilitators and coaches, cannot.

In the Retrospectives with our team, I ask them to think about the Results, the Experience and the Process of Agile and the sprint. I view my Scrum Master role as critical to helping the team to not only achieve great results (velocity) but to enjoy the experience and the process- just like my high school soccer coach did all those years ago!

A Fresh Look at Retrospectives

It’s been a few months since I wrote the Agile Life series and I came across a new way to think about Sprint Retrospectives.

What if we asked these 3 questions at the end of every life sprint ( 2-4 weeks)?

1. What am I going to start doing?
2. What am I going to stop doing?
3. What am I going to continue doing?

Food for thought Grasshopper…..

20140507-145514.jpg

An Agile Life- Part 3

To conclude my Agile Life series I’d like to expand on the last two concepts that are key to implementing your Agile life.  Again, one of Stephen Covey’s habits for highly effective people is incorporated in them and that is  “Sharpen the Saw”.

  1. Timeboxing (Sprinting)
  2. Backlog Creation
  3. Backlog Refinement
  4. Review and Retrospective

Item #3 is a productive and adaptive feature of the agile process and involves the continuous Refinement of your Life Backlog.  This is a time toward the end of every sprint when you look ahead to the next few sprints and plan what you are going to focus on and accomplish next.  It’s your time to relook the order of your items and move them up or down in priority based on your needs and desires.  It is also a time when you can add or remove items from your backlog based on changes in situation.

The final component of your Agile Life process is the Review and Retrospective.  This is done on the last day of every sprint and is an ongoing process. It is a review of what you accomplished.  What did you do well and what didn’t go well during the last 2-4 weeks of sprinting?  What were your results and achievements?  Did you complete all of the User Stories that you committed to in your sprint?  If not, do you want to add them to the next sprint?

MIRROR02_a

Other things to reflect on during your retrospective are your thoughts and feelings on the process and experience of Agile.   What did you like about it?   What did you hate?  What could you do better next time to be more efficient and effective?  What could you do differently in the next sprint so that you are more productive?  Specifically, you should strive to take action on one of improvement items from the Retrospective and immediately incorporate it in to your next sprint.

Agile’s continuous improvement (sharpening the saw) aspects are powerful.  The process facilitates SMART goal setting and the time boxing is key to increased levels commitment.  The frequent reviews and refinements helps you change course sooner rather than later.

close-up-of-a-jagged-and-sharp-saw-blade

Living an Agile life requires a bit more planning and discipline in your activities but the rewards will be great. If the process is a bit unproductive and awkward at first, don’t give up!  Most agile teams don’t find their rhythm for 3-5 sprints.   Give it a try for a few sprints and let me know how it goes.