Business Analysts, Public review of BABOK Guide Version 3 open!!


International institute of Business Analysis (IIBA) today announced the public review of Business Analysis Body of Knowledge (BABOK) Guide version 3 (V3) is open until July, 11th 2014.

Business Analysis experts, practitioners and enthusiasts from across the world participated in creating the updated version. Many of these individuals volunteered there time to shape the future of business analysis profession.

It takes a great deal of commitment, experience and patience for such efforts to go from concept, planning, initiation to making it open to Public review.

I have experience in such a globally distributed effort for Project Management Institute’s (PMI), PMBoK Guide 5th edition project and have high respect for members contributing to make a difference to their profession.

If you are involved with profession of business analysis or know someone on your team (regardless of being an IIBA member), I suggest to get involved:

1. Further your knowledge of Business analysis
2. Use your experience to validate or refine the content
3. Gain knowledge from the experts by just reading through the BABOK

All details regarding the effort are at:

After all volunteering is rewarding experience, personally and professionally. I am sure current IIBA members can gain some continuing education benefits!!

Being an Agile Coach – Making Effective Decisions

change-ownership-agile-decisionsMAKING EFFECTIVE DECISIONS

Decision-Making is obviously one of the major functions of the Agile coaching process.

Myths of Decision-Making:

  1. The higher up the decision is made the better it is. So, if the President makes the decision it is obviously a better decision than a decision made by a Vice-President. This is not better because we will be moving back to centralization where one person dominates everything. Decisions tend to naturally go up the organizational chart eventually anyway.
  1. The longer we consider a decision the better the decision will be. This is not always the case. But decisions can grow stale and stagnate if dwelt upon too long. The more complex the issue, though, typically more time needs to be allotted… not to think… but to experiment!
  1. A good decision made late is better than a mediocre decision made early. A decision that will really benefit a team needs to be made early rather then last minute. Precious time is often wasted in the lollygag scenario. Time factors often dictate that a decision must be made. And even if the best decision is not made, at least a decision was made in time.

Causes of Ineffective Decision-Making:

  1. The lack of clearly-defined goals and objectives. People don’t act because they don’t know which direction to go. Decisions can’t be made to do things that haven’t been previously decided to do.
  1. Insecurity of position or authority. Decisions are postponed because the leader  is afraid of the possible consequences.
  1. Lack of information – no alternative seems clear OR all alternatives seem viable.
  1. Desire to retain the status quo or simple fear of change – there is comfort in the comfort zone. But still, because things change and the team needs to develop and change as the market changes.

The Problem-Solving Process of Decision-Making:

Decisions are made, typically, to solve problems:

  1. The orientation to the situation – we get familiar with the background of the problem. Analysis, experience, training, skill, and administrative intuition are helpful in determining the truth of the situation.
  1. The identification of key facts – we will never have all the facts but we can get the facts that truly identify the reality. Utilize effective questioning. We want to ask “open” questions that will give us information rather than a simple yes or no. Carefully sift through the information and deduce logically
  1. The identification of the major problems in the situation: Look for the causes of the effect that have been seen or demonstrated. Why are things happening the way they are? What caused this issue? Again, carefully sift through the information and deduce logically. Get insights from others who can give information from another perspective.

Often, the unique situation you are in requires you to do a lot more research and problems solving to help leaders make good decisions… At the end of the day though, I would suggest, always taking an empirical approach. Experimentation is key. The more you experiment… the more you can learn quickly!

Being an Agile Coach – Dealing with Conflict


The word “conflict” tends to stir up emotions in corporate America. Few companies want to find themselves in conflict. Most employees will view conflict as a bad thing and something to be avoided at all costs. But some conflict can actually be healthy. The reality is that disagreements do not have to turn into fights. We can keep our differences in check if we have a few basic understandings regarding conflict. Conflict occurs when two or more people with mutually exclusive viewpoints attempt to solve a problem.

Two kinds of Conflict (healthy and unhealthy)

Conflict is unhealthy when it negatively impacts the company or team by hindering or limiting their ability to do productive work.

Conflict is healthy when the opposite occurs. When conflict is viewed and handled appropriately.

We know conflict is unhealthy when:

  • People no longer calculate their remarks to edify or change others. Instead, they plan their remarks (often unconsciously) to hurt, demean, defame, or even destroy another
  • People begin to question whether their relationships can weather the storm of difference
  • People feel rejected by those who were once considered friends
  • People feel they have no control and the odds are against them
  • The pain of the competition is greater than the exhilaration of the challenge
  • People make accusations, and it seems that “others” want to destroy or split relationships down the middle.
  • People use words that have violent connotations

Conflict is healthy when:

  • The people involved feel confident they can manage the differences
  • Those involved adhere to firmly to decision-making processes authorized by the team and working agreements of the company
  • People operate within the specifically stated, generally understood rules of appropriate behavior in the company
  • People cooperate in the process suggested by the leadership

Reactions to conflict

  • Conflict is wrong.

Some individuals believe that conflict is always wrong. The mindset is that people in a copmany should be in agreement and live in harmony. They become nervous when team members express differences of opinion. They “lovingly” try to encourage people into one opinion. The attitude does not acknowledge that legitimate differences can exist among different people.

  • Conflict is an opportunity to exercise power.

Some people view any discussion as debate and any issue as a time to win at any cost. These people get their thrills in the competition of the moment. Winning the issue is oftentimes far more important than the issue itself.

  • Apathy (this doesn’t involve me)

Some people do not care much about the outcome of the issues involved. The apathetic spirit comes from several sources including burnout, fatigue, stress, a defeated spirit, or a different set of priorities.

  • Personal affect (this does involve me)

Some people do have a considerable stake in the outcome. These often include the leader, staff, board members, managers, and other directly involved individuals. People often believe that the outcome will affect their reputation and/or their feelings of self-worth. Oftentimes the emotional involvement clouds an individual’s reasoning and judgment surrounding an issue.

  • Conflict might split a company

Some people become nervous when any disagreement occurs in a company or team because they believe it will divide the team needlessly. These individuals many have vulnerable feelings left from past conflict that was handled in a hurtful way. Whatever the reason, they tend to sweep all controversial issues under the rug and hope they go away. They would rather stay in a bad situation than risk the unknown.

Responses to Conflict Continue reading “Being an Agile Coach – Dealing with Conflict”

Peter Saddington Session on the Science Behind High Performance Teams #agile2013

Dear Peter,

Thank you for being a part of Agile2013. Following is some information about your session.

  • Number of attendees at the beginning of your session: # 170
  • Number of attendees at the end of your session: # 170

We asked attendees to indicate whether they would recommend your session to their peers:

  • Yes (Green): # 120
  • Maybe (Yellow): # 3  ***CANT PLEASE EVERYONE*** 🙂
  • No (Red): # 0


Agile Alliance Team

Had a great time! Thanks Agile Alliance!

Below is the scribd version:

Action & Influence – The Science of High Performance Teams Teams Agile2013 Peter Saddington FINAL

User Stories – Tackling team commitment through “leftovers”

Happy New Year @gile$cout readers!

Be it teams new to Scrum or ones that have been practicing scrum for a while, one of the common problems they face is: User stories carrying over multiple time boxes (sprints/iterations). The team simply can NOT finish the story and it drags on..and on..sprint after sprint.

As a member of ever growing agile community, I am subscribed to many discussion groups. Recently, one such discussion Can’t get to done, roll-over every sprint on Scrum Alliance Google Group caught my attention.


The origin of the problem can be at many places like: Ambiguous requirement(s)/stories, Stories not sliced enough, Business owner/PO availability, Technical road block, Team member availability etc. One of the common cause is “over commitment”.  I’d like to share my recent experience about this specific problem and how I was able to address it.

Setting: Most of the team members were new to scrum/agile. 3 Sprints into the product development, our team was continuously moving more than a couple of user stories from sprint to sprint. Apart from the obvious problem of inexperience with user story creation and splitting, there was a zest in team which was leading to over commitment.

Having failed to try and discuss that problem in retrospectives, I had to wait for around 3 sprints to validate my assumption. (Yes, we progressed into creating better stories and got a little better at slicing them). After 3 sprints, I decided to try something different – I created a new backlog item “Spillover” stories for the next sprint. Since Thanksgiving was approaching people started talking about Turkey dinners and thus the “leftover” turkey sandwiches and all sorts of leftover recipe discussions were making rounds in office and internet. That inspired me to use the term “Leftover” stories.

At every daily standup, we would discuss about the “Leftovers”. And as it happens in every household, there came a day when the team got bored with leftovers. One of our developers broke the silence saying, “..I don’t like the term leftover/spillover you are using..”. The developer was concerned that the task board was not doing justice to the status of work completed in that story. That was the opportunity, I was waiting for.

We agreed to finish the standup and then discuss the issue. With everyone from the team present there, we looked at the stories, work history, capacity of every team member and turned the discussion into a retrospective. Everyone agreed that we had gotten better at describing the user stories, creating supporting documents/design/User interface. The team then realized given the time box, we were biting more than we can chew. For the first 3 iterations, we all were ignoring the fact as the team was forming, storming. It WAS a team commitment (or “lack of” to say NO to the product owner) issue.

This experience touched many aspects of the team’s operation, but mainly addressed the commitment issues. We do have some scrum certified team members but until we practice, fail, inspect-adapt and repeat the cycle, we are not being true to agile values and principles. It was a wonderful experience for me and the team and we all have made adjustments since then.

Many other scrum/agile experts offered excellent advice/response to that thread on Scrum Alliance Google group. I shared this story very briefly. I was delighted to see @RonJeffries responding to my response on the group as “Nice!” Made my day! [blackbirdpie url=”″]

[blackbirdpie url=”″]

Thanks to @WoodyZuill for encouraging me to create this post out of a twitter conversation! [blackbirdpie url=”″]

If it helps, here are some of my User Story related valuable reads. I know it’s time to update that list! I am eager to hear your comments and stories.

Becoming a Certified Scrum Trainer – CST

[I was recently asked what my journey to become a CST was like. So like an Agile blogger, I told them to wait for it to post on 🙂 ]

The path to becoming a Certified Scrum Trainer (CST) is one of the most arduous yet rewarding experiences I have ever gone through (and I spent 7 years in Master’s programs!). It has not only stretched me, but brought about a greater understanding of “mastery” of a craft, that, no matter how good you ‘think’ you become at something, you can always improve, become better, learn more, and grow as a person.

The day you stop learning is day you become ineffective in your work.

My CST Journey

I began my journey to becoming a Certified Scrum Trainer back in early 2009 when I began my investigation into the process and started collaborating with other CST’s about co-training opportunities. This was a time when the CST application process was evolving (and still is) and the requirements and application process wasn’t fully fleshed out. I, at the time, had been in my 8th year as an independent Enterprise Agile Coach and felt like the CST was the right way to go. I had completed my Certified ScrumMaster designation and my Certified Scrum Professional designation previously.

In early 2009 I had my first co-training opportunity with a fellow Agile coach. They went very well. I was stoked. I was excited. I had gotten a great review and was given priceless advice on how to become better. I felt like the CST was fast becoming a reality. I flew out to meet my 2nd co-trainer and we trained together. Another great workshop. I felt great… Then:

  • Client work picked up.
  • Timing just wasn’t working out.
  • Work-life balance just wasn’t what it used to be.

A full year later, I still had yet to co-train with other coaches and trainers. My client list was full, my schedule was so tight that it became apparent to me that I may not be able to finish this race due to scheduling conflicts and overall timing not to mention funding from the CFO of my house (wife). I was burnt out, tired, and a bit frustrated.

It was all about the timing. It just didn’t seem to work. So what did I do? I made the tough choice to lighten my client load (OUCH! SCARY!) so I could open up opportunities to co-train. I made the time available, I reached out to friends and fellow Agile coaches for time slots, and I invited Agile coaches to come train with me at my client sites. I patiently prayed that the opportunities would come… and they did.

After a full 3.5 years I completed it… The road to becoming an official CST was complete… but the journey forward has just begun. YES!

[Peter Saddington Training on ScrumMaster Roles]

On Co-Training Continue reading “Becoming a Certified Scrum Trainer – CST”

Getting back online: Agile, PMI, Volunteering and Me

*** Disclaimer: I am an active volunteer with PMI’s Agile Community of Practice as one of the 5 official leads. Views expressed here (and related future posts) are my own and not an endorsement by Project Management Institute ® (PMI) or Agile Community of Practice (CoP) leadership team.***

If you know me, I have been pretty active (as a volunteer, lead and contributor) in PMI + Agile space. I volunteer as:

  • PMBOK® Guide 5th edition – contributor (engagement just wrapped up)
  • PMI Atlanta Agile Interest group – Program Manager for Agile Interest Group
  • PMI Agile CoP – Knowledge Management lead

These opportunities have allowed me to connect with lots of people – amazingly talented, some famous agilists, practitioners and gurus. There’s a common thing we all share – desire to learn coupled with the passion to share!

I have learnt a lot, have actually got hands on experience (tools, technology, principles, practices etc.),  mentored a lot of people and I am still enjoying the journey!

What do we share? Knowledge. Of course about Agile, primarily.

I have seen a lot of questions that follow an agile presentation or discussion, ranging from:

  • What is Agile?
  • Where do I start? (There are so many places to start with)
  • What is different at Agile CoP? (from other valuable sites, groups and resources)
  • What does a Project Manager do in Agile projects?
  • What is PMI’s – Agile Certified Professional (PMI-ACP®)  certification? Is it for me?
  • Whom do we trust as good training companies?
  • What are good books, blogs, sites to start/continue building my knowledge about agile?

and many such questions. Continue reading “Getting back online: Agile, PMI, Volunteering and Me”

The Agile Pocket Guide – Peter Saddington – Now on Amazon for Pre-Order!

Super excited that my next book: The Agile Pocket Guide is now up on for pre-order!

It’s been a long road since I first got rejected by many publishers and finally self-published and then grabbed Wiley’s attention!


Business Optimization and Human Potential

We are often blind.

As Agile Coaches, consultants, and organizational improvers, we strive to help teams and businesses alike improve their performance, output, and even culture.

The problem is… that we often come into a team or business blind, not understanding the full context of each team and each individual who makes up that team.

This is a problem.

To be the most effective we need to understand how people operate. We need to understand how they work collectively, as a group, as a team, and as individuals. The quicker we can assess and understand the contextual culture of our clients and teams, we are left to empirically deduce assumptions that most often are half-truths.

As we jump into consulting or coaching with any client, it would be great to know their cultural context, how people are behaving, and even how to engage with them best.

Easier said than done, until TeamScience™ dropped on the scene.

TeamScience™ – Business Optimization and Human Potential

Continue reading “Business Optimization and Human Potential”

Achievements: An Agile Whitepaper

An Agile Whitepaper: Achievements

By, Renee Troughton


Abstract: Agile Achievements can be used to track and celebrate both individual and team behaviors in adopting Agile values, principles and practices.

Gaddie Pitch: You know how most teams find it difficult to know what they have to do when developing in an Agile environment?

Well what Achievements does is help to give clear goals about the expected behaviors for teams and individuals.

In fact Achievements can be fun and re-direct the focus away from the Scrum Master or Agile Coach to enable the team to encourage better Agile behaviors.

What is an Achievement?

Continue reading “Achievements: An Agile Whitepaper”

[Review] – Mike Cohn’s eLearning Agile Videos

Online Agile Videos

Mike Cohn recently announced that he’s providing a kick butt online eLearning tool to learn all about Agile. I reached out to him to see what it’s all about and we kicked a few emails back and forth. Regardless, I went ahead and got my hands on it. That’s what AgileScout is here for: Do the heavy lifting for you 🙂.

[Mountain Goat Software Online eLearning Agile Course] LINK

With so many Universities doing online learning these days, wouldn’t it be about time for Agile and Scrum Trainers to start offering online training tools? You’betcha. Who better to do it than Mike?

Here are my thoughts and experiences after a full 3.5 hours and taking all 9 of the tests:

Agile Topics Covered

  • Introduction
  • The Problem
  • Iteration Planning
  • Story Points & Ideal Days
  • Estimating the Product Backlog
  • Release Planning
  • Other Topics
  • Conclusion
I was captivated by the introduction video of a goat running around. Fantastic!

Review of Course Presentation Continue reading “[Review] – Mike Cohn’s eLearning Agile Videos”

Woman in Leadership – Top Women in Agile Thought Leadership


[Click the image on the right for a full size infographic of the growing numbers of women leaders!]

I am very happy that women in leadership is growing. Having both sides of innovation and thought leadership from both males/females will create more dynamic environments that will product better products. I believe it!

I am truly excited that slowly but surely my RSS feeds are growing from women in management and executive positions. There is a TON of great stuff to read by women in leadership.

What I’m even more excited about is how my RSS feeds are growing to include female developers/coders and fellow nerds/geeks alike. I have a daughter and my hope is she will love technology (code?) as much as I do!

Here is to a better future!


[In no specific order, according to my RSS feed, and who update frequently]

Interestingly enough, most of the women stated here are also part of the [Top 200 Agile Blogs] as well (make sure to check that out). Congrats!


Grab either badge if you’re a woman blogger and link to this post! Show your pride! 🙂

I am SURE I missed some other women leaders. Please let us know in the comments!

ScrumMaster Daily Check List

There is a reason why when you get on a flight the two pilots go through an intense check list. Why? Because check lists work. If you are the Perfect ScrumMaster, who passed all the ScrumMaster Interview Questions, this checklist may just help you:

Each day

  • Can you see the taskboard?
  • Does it have a full set of stories/tasks?
  • Does the client know what’s been committed to on the board?
  • Has it been updated since yesterday?
  • Are there ‘you are here’ arrows?
  • Are there stories awaiting done-done checking?
  • Can you see the burndown?
  • Has it been updated since yesterday?
  • Is it under the glideslope?
  • Can you see the release plan?
  • Do you know what’s likely to be in the next iteration?
  • Are most of next iteration’s stories now unblocked?
  • Has there been a daily stand-up?
  • Can you see the demo date? Is everyone who’s needed attending?
  • Can you see the product owner’s name and contact details?
  • Does the team believe in what they’re building, and why?

Each sprint

  • Are there cutoff lines (with risk multipliers) on the release plan?
  • Have all the clients seen the RP? Is there a stealth client?
  • Do all the clients know the current velocity? Do you?
  • Have we been paid for this iteration?
  • Is there one email per completed iteration, showing stories completed, velocity, risks and projected scope?

Kanban Applied to Scrum

I enjoyed this short and concise video on Kanban.

Kanban is a lean Agile methodology.

Kanban is a visual queue of work and helps with, as BTI360 states, the issues around unclear development steps, task switching, and partially done work.

  • Kanban helps with unclear development steps in that Kanban helps the team visualize flow of work and high level transparency to involved stakeholders.
  • Kanban helps with constant task switching in that Kanban helps by placing work-in-progress limits so that team members can focus on completion of work or value.
  • Kanban helps with partially done work in that Kanban helps by delivering fully complete work 100%.
Highly visible flow helps team address bottlenecks and on-demand improvement. Adjustments are made as they surface.

PMI-ACP Exam Tips

Actually... Don't Click Me.

We at AgileScout received a cool email about tips from someone who recently took the PMI-ACP Exam, see the details below!

[See my experience with the PMI-ACP here]

“I took the PMI-ACP certification examination on 6th October in Chicago.”
My overall experience of taking this exam is as follows:

  1. Time: The 3 hours to answer 120 questions were sufficient. I finished answering all questions in 2 hours. There were 4-5 questions which were not very clear and another 10-12 questions I marked for “review” later. I used my extra time to review those Marked questions to guess best answer PMI may be expecting.
  2. Agile Practices: There were multiple questions on SCRUM and XP, very few questions on Kanban and Lean, almost none on Crystal, FDD, and DSDM.
  3. Roles: Fully Understand the Roles in SCRUM and XP, what are the responsibilities carried by those roles, various meetings, input and outcome of those meetings like review, retrospective etc,
  4. Scenario Based Questions: There were multiple questions based on scenarios and how best will you apply Agile practices under those scenarios.
  5. Understand the difference between terms of coordination, collaboration and communication. Multiple questions on team Collaboration.
  6. Surprise questions on Agile Portfolio Management.
  7. Multiple questions on Agile Risk Management.
  8. Multiple questions on Story Points, Burn-down Charts and Velocity calculations.

Overall PMI ACP certification exam is challenging and tests the knowledge of Agile Manifesto, Agile Principles, Agile Practices, and Agile Methodologies very well. If you read the PMI suggested material, PMI suggested books, I am sure you will PASS the certification examination with flying colors!!

[Thanks Vivek!]

*It has come to our attention that this was forwarded from someone who had received an email update from William Fumey of Sorry for the repost!

Agile Innovation Games

We here at AgileScout love Innovation Games. We’re all about making work more exciting, engaging, and worthwhile to everyone involved. Work doesn’t have to be a drag. We’ve covered a couple topics on this before:

Thanks to Luke Hohmann we’ve been resourced with some of the top games. We decided to drop them here for all you Agile coaches to utilize. Have fun! Continue reading “Agile Innovation Games”

Agile Transformation Walkthrough

What I love about being an Enterprise Agile Coach is the ability to work with great clients who not only love Agile, but have fully transformed their entire business around it.

The video above is an example walkthrough of a business that I had the pleasure of completing an Agile transformation with. The transformation included:

Want to know the most rewarding thing about this client engagement? The fact that they embraced Agile so much, they are now teaching Agile to their clients. Talk about awesome!

Agile Simulation Group Exercise and Walkthrough

Brian Bozzuto over at put together a fantastic Agile Simulation exercise during the recent PMI North American Global Congress that happened recently.

We liked these resources so much we thought we’d share them with a wider audience!

The purpose of this exercise is to introduce the mechanics of an Agile project and to highlight the role of the Product Owner. In Brian’s words:

“Many people at the end of the simulation came forward and talked about how powerful it was to have someone speaking on behalf of the business there for the whole simulation. The team got to feel the power and collaboration of showing a business partner real time progress and making changes based on how they were doing. For some of us who have been preaching Agile and Scrum for a while, this may sound patently obvious.”

Below are the (very cool) templates for Agile Charts and Task Boards. Make sure you download them!

Continue reading “Agile Simulation Group Exercise and Walkthrough”

Top 200 Agile Blogs RSS + Twitter Lists

I’ve gotten quite a lot of emails asking for the RSS. Well here you go.

Clicking these links are the fastest way to subscribe to the blogs that you want to follow. I decided to create the list instead of drop an XML file on you all. This way you can pick and choose which ones you want to follow.

For full details on the Top 200 Agile blogs go here.


Continue reading “Top 200 Agile Blogs RSS + Twitter Lists”

Agile Blogs Top 200 – Update

I’ve received many emails about the ranking system for the Top 200 Agile Blogs list.

The picture above is what I’ll be working on for the rest of the week so that means no NEW blog posts (I’m tired).

What does this mean for you?

  1. You have a chance to state your peace and enter your blog into my system by 6/9/2011 at 11:59PM.
  2. If you feel like I have missed your blog, please comment on the Top 200 Agile Blogs post.
  3. I will run you through the program and see if you’ve made the cut.
  4. BTW – Some blogs have already been bounced due to algorithm anomolies. For example: If a total blog has 0 Alexa, 0 Compete, and 0 RSS and is tied for that number with others, they receive a similar grade, interestingly enough, they get a points for shared ranking, which is the reason why you see a couple of blogs on the list with relatively zero influence… those are now gone.
  5. I like to give people a fair chance. So grab your chance to get into the top 200 list.
  6. I’ll also be adding an Honorable mention section past the 200.
  7. I’ll also be editing the post so you can grab the RSS feeds for each of the top 200 as well. Aren’t I swell?

Top 200 Agile Blogs

[If you’re not on this list and would like to be considered, post your blog information in a comment at the bottom!]

There are hundreds of great Agile blogs and software development blogs to read, but do you ever wonder which Agile blogs everyone else is reading? Ever wonder which ones are worth reading?

I do. I burn about 1400+ RSS feeds of Agile and software development blogs (growing weekly) with people emailing me monthly for my RSS XML file.

Here are the best 200 Agile blogs out there for 2011. Some focus exclusively on Agile and coaching, while others are more on leadership, news, consulting, Product Ownership, ScrumMastering, and specific Agile methods. Regardless of how you label them, these are the world’s most popular Agile blogs written by many of today’s most influential Agile leaders, practitioners, coaches, consultants, and hippies.

Want to brag about your rank or give some link love to the Top 200 Agile Blogs list? Embed the badge at the bottom of this page on your website.

For a legend and to understand how the rankings are computed, scroll down past the list.


As of June 3, 2011 – Updated on June 8 with new data and changes.

[Click here for the Top 200 Agile Blogs RSS links!]

Continue reading “Top 200 Agile Blogs”

Essential ScrumMaster Interview Questions

[The following is an interview format that I created for a client of mine for interviewing potential ScrumMaster candidates. The interview includes basic Agile questions, Agile experience, and 3 core exercises to see facilitation techniques and ability.]

***Make sure to view these questions in tandem with the ScrumMaster Characteristics!***

The outline isn’t perfect, and many questions come up ad hoc through the conversations with the candidate. Some of the questions are hard, but not unreasonable. I would believe that a well versed, seasoned ScrumMaster would intuitively know the answer to most of the questions. I may be wrong, feedback is welcome!

Scrum Master Interview Questions

Experience – General

  • Start with a standup. Introduction! 🙂
  • Current experience, etc. etc.
  • What is Agile? What would be your 30 second Agile elevator pitch?
  • What is the difference between Agile and Scrum? / What are some other Agile methods/frameworks?
  • What is missing from Scrum? What other developmental practices would you suggest helps with providing deployment value to a software development team?
  • Why is the daily standup/Scrum valuable for the team? – How do you make an ineffective standup more effective?
  • Your team is ready to plan (sprint plan) for work on Wednesday, but the requirements (stories) aren’t ready yet. – What type of planning would you do? / How would you lead your team to be ready to start developing on Wednesday?
  • What is a Scrum of Scrums? Why is it valuable? Continue reading “Essential ScrumMaster Interview Questions”

ScrumMaster’s Retrospective with Management Agenda

If your company has multiple teams with multiple ScrumMasters, how would you hold a ScrumMaster retrospective?

Remember: The purpose of the Retrospective is to take the opportunity to examine the past release and identify opportunities for improvement.

I’ve found that the following agenda has been useful for holding these types of ScrumMaster retrospectives (timeboxed to an hour).

The agenda for the Management Retrospective will be:

  1. Establish focus for the retrospective and share the plan for the meeting
  2. Review data from the ScrumMasters and identify important events that happened
  3. Generate insights through understanding root causes of events and build awareness to the group
  4. Focus on root causes and identify things that the management team can accomplish and improve
  5. Re-iteration of issues and follow-up commitment by management

ScrumMasters need to come prepared with:

  1. A printed out burndown chart of your team (large print out preferred)
  2. One (1) team specific event that needs escalation or focus from the management team
  3. One (1) enterprise issue that needs management visibility
  4. Each ScrumMaster will be given a 8 minute timebox to present on issues.

The main purpose of using the burndown chart is to make sure that the issues the ScrumMaster’s face are backed up by data. Conjecture and ambiguity has no place here. During the retrospective, we’ll go through each of the ScrumMasters and use stickies posted to where the burndown shows issues.

What else would you add to this ScrumMaster’s retrospective agenda?

[Guide] – Create the Perfect Agile Workshop

So much of my job as an enterprise Agile coach is crafting fun and engaging workshops for clients. I was asked recently by another Agile fellow about how to build the right workshop for engaging the audience.

“Great question!” I responded.

“It all begins with crafting the content and experience for the attendees.”

Creating the Perfect Agile Workshop

1. Crafting the Workshop in [10 Steps]

2. Crafting the Experience in [5 Steps] +1 Extra

Crafting the Workshop

  1. Set the Stage – Begin crafting the workshop content by setting the stage for the workshop. What is the focus of the workshop? Who is the audience? What are the types of questions that your audience will most likely have? If you were a participant, what questions would you have? What material makes sense for this particular client or environment? By setting the stage for yourself, you will have a greater understanding of how to present the workshop to the specific audience.
  2. Define the Content Goal – What is the main purpose for this workshop? Is it an informative workshop, and educational workshop, seminar, working session? Create a goal statement that you will share with your audience so they know exactly where you are headed. Let them know what the workshop will entail and give them a brief synopsis of what lies ahead. Get them excited about whats going to happen.
  3. Give Away Free Stuff/Swag – I love giving away free stuff. Not only is it fun, but it gets your audience engaged! I always give away something pertinent to the audience and it usually is in the form of a couple books, work-related material, or even just free technology! *Notice how this is plural. Give away something at the beginning and at the end. The more the merrier! Continue reading “[Guide] – Create the Perfect Agile Workshop”

Top 10 Essential Product Owner Characteristics

We’ve written a bit about the product owner before:

  1. Product Owner Top 10 Backlog Tips
  2. 4 Questions a Product Owner Needs to Answer – In order to give good direction about a product
  3. 7 Product Owner Responsibilities and 4 Product Owner Artifacts
  4. Product Owners are VIPs – The PO tells us what to build!

Now we’re going to give you…

Top 10 Product Owner Qualities and Characteristics

  1. Engaged leadership – The best Product Owners are engaged in the entire process. A dis-engaged PO finds himself outside of the process quickly. An engaged product owner is a natural leader. He finds himself leading a team through his decisions and makes it apparent to the team that he is committed to not only the process, but the final product as well.
  2. Available within reason – The best Product Owners are available to the team, but within reason. There is something about co-locating oneself within the team so they have zero walls to climb in order to receive feedback and potentially daily guidance. The availability can come at a cost though, with an immature team who is lacking the accountability and responsibility of building the needed project. Be tactful here and give a healthy balance between availability and baby-sitting a development team. Sometimes helping them help themselves can create a partnership between team and PO that reeks of productivity!
  3. Informed about the product – The best Product Owners know the product inside and out. Noobs need not apply here. Subject matter experts on not only the product but also the market will find themselves the best prepared for giving updated feedback and guidance to a development team. Understanding beyond the product can help here as well, but core to the Product Owner role is their ability to intimately know and understand the product or product set they are helping a development team build. Continue reading “Top 10 Essential Product Owner Characteristics”

[Product Owner] – Top 10 Backlog Tips

Lists rock. They’re even better when someone has put together an awesome list for public consumption. Upon thinking about how to better use your product backlog as a Product Owner, consider the following helpful guidelines [distilled for a quicker read].

Top Ten Backlog Tips

  1. One product at a time – Derive your product backlog from the product vision or the product roadmap.
  2. Detailed – Make your product backlog as detailed as possible.
  3. Be structured – Group similar items items into themes.
  4. Visible – Put your backlog up on the wall.
  5. Focused backlog – Start with many, but have the courage to weed out other items over time.
  6. Capture functional requirements – Start with large, coarse-grained stories and progressively decompose them over time into detailed ones utilizing customer feedback.
  7. Start with risky stories first – Use risk/uncertainty, dependencies and releasability to decide how soon an item should be implemented. Addressing risky items early on allows you to fail fast.
  8. Manage global nonfunctional requirements carefully – Describe them precisely upfront. Capture operational qualities such as performance, robustness and interoperability as constraints; describe usability requirements visually, for instance in form of sketches, mock-ups, and screen shots.
  9. Housekeeping – Groom your product backlog regularly and collaboratively. Run weekly grooming workshops with the team to ensure that your backlog is in good shape. Involve stakeholders including customers and users as appropriate.
  10. Be ready – Make sure the top items are always “ready:” clear, feasible, and testable. This allows the items to flow into the sprint and facilitates a firm commitment.

[VIA: Roman Pichler]

[Agile Guide] – Estimating User Stories in Agile

As a developer, we have the toughest role throughout the project lifecycle: Estimating our work. The business (typically) puts so much at stake onto the developer for elaboration and understanding about the time and schedule of a project. It’s a tough life for a developer.

But fear not! There are resources to help you estimate your stories.

One great article we recently found was by Nicole Rauch, she states when when estimating a story you need to take into account several things:

  • Complexity: Consider the size of the story.
  • Risk: Consider the teams inexperience with developing this story.
  • Implementation: Consider the implementation factors.
  • Deployment: Consider the deployment requirements.
  • Interdependencies: Consider other outside issues.

We would add that developers should begin (over time) to develop a baseline for estimating sizes of stories. Use examples of past stories that can help developers understand relative sizes. Ask questions like: “How does this story compare to X-story we did before? Bigger or smaller?”

Now, the question really is whether you use points or hours for estimation. Mike Cohn suggests to use points for product backlogs, and hours for tasks.

Bottom line? Agile estimation is an art form that grows better over time. As your team matures and developers a solid baseline for estimating work it can produce a consistant cadence or velocity that is (somewhat) predictable for the long run, but not great at estimating short durations.

Find out more:

Agile Estimation and Planning- Peter Saddington

[HT: pBoop]

The Perfect ScrumMaster Job Description

[Go here if you’re looking for ScrumMaster Interview Questions *POPULAR POST*]

I was commissioned by a client to put together a ScrumMaster character profile for helping them choose good great ScrumMasters to join their team. Please do notice that no where in this job description is certification. I believe that a good great ScrumMaster is all about the character.

A high performing team, an active and involved Product Owner, and business support can help a new ScrumMaster do their job very well. Character, however, isn’t taught, it’s grown.

Top 10 Personal Skills for a ScrumMaster:

  1. Servant Leader – Must be able to garner respect from his/her team and be willing to get their hands dirty to get the job done
  2. Communicative and social – Must be able to communicate well with teams
  3. Facilitative – Must be able to lead and demonstrate value-add principles to a team
  4. Assertive – Must be able to ensure Agile/Scrum concepts and principles are adhered to, must be able to be a voice of reason and authority, make the tough calls.
  5. Situationally Aware – Must be the first to notice differences and issues as they arise and elevate them to management
  6. Enthusiastic – Must be high-energy
  7. Continual improvement – Must continually be growing ones craft learning new tools and techniques to manage oneself and a team
  8. Conflict resolution – Must be able to facilitate discussion and facilitate alternatives or different approaches
  9. Attitude of empowerment – Must be able to lead a team to self-organization
  10. Attitude of transparency – Must desire to bring disclosure and transparency to the business about development and grow business trust

Technical Skills:

  1. Understand basic fundamentals of iterative development
  2. Understand other processes and methodologies and can speak intelligently about them and leverage other techniques to provide value to a team/enterprise
  3. Understand basic fundamentals of software development processes and procedures
  4. Understand the value of commitments to delivery made by a development team
  5. Understand incremental delivery and the value of metrics
  6. Understand backlog tracking, burndown metrics, velocity, and task definition
  7. Familiarity with common Agile practices, service-oriented environments, and better development practices

*The above technical skills are nice-to-have, but not necessarily required!


[Tip] – Agile User Stories – Specific Role Names (Personas)

Quick tip for today from Michael Bosch:

Make sure you write down a [specific] role when you write a story, also called a “persona.”

Make your user story more valuable to a reader by giving more specifics about the user.

For example:

As a [customer], I want to [save my session], so that I can [return and complete the form later].

A better way:

As a [returning user / un-registered user / super-user / admin / etc.]… I want to… So that…

“This level of specificity could provide valuable insight into the intended audience and how best to implement the feature.” – Michael Bosch

Thanks Mike!

[HT: MikeBosch]