Scrumptious

Recently I was in a discussion with a key resource for a Scrum project in one of Australia's most recognized corporations. After a brief discussion, I was beginning to wonder if this project was indeed Agile or Agitated. The resource, a member of the Scrum team, said they sometimes had daily stand-ups, had an Agile board that was rarely updated, a semi-co-located work area using hot-desks, and no War Room.

The first thing that came to mind was: "This isn't Scrum." The first thing that came out of my mouth was: "Why?" Over the course of the discussion, there was many reasons given as to why these Scrum anti-patterns were occurring, but for the purposes of this blog post, I will focus on why a War Room is a good idea for Scrum Teams.

What is a War Room?

A War Room in most often a meeting room used exclusively by the project, where teams meet together and collaborate on important project issues, and a place where they can see everything about the project at a glance with the assistance of information radiators. Having said that, in an Agile or Scrum environment, the open workspace incorporates the "War Room" usually around an Agile Board or close by. Co-located teams sit within earshot of each other, and everything that needs to be known about the project is displayed visually within a few short meters from everyone. It is a central repository of relevant information that fuels the decision-making process.

Why do we need a War Room?

To get things done, collectively! The best minds for the project are always in the War Room. These are the individuals who are the Generals of Agile action, and they strike with devastating value when the machine is well oiled with correct user stories. The information radiators are kept updated so the enemy (non-value) cannot get the upper hand.

What should be in a War Room?

There are so many things to make a War Room really effective, but here are some key things to include:

The Scrum Team
That doesn't just mean the developers. The Product Owner should be there some of the time at various stages of the day to answer questions and work with the developers. The Scrum Master should be there most of the time, unless removing impediments or assisting the organization or stakeholders transition into the Scrum process or project smoothly.

Information Radiators
Anything relevant that can be displayed visually: burndown and burnup charts, Agile Boards (Kanban without the pull system), story cards, sticky notes, flip charts, Sprint Goal poster etc.

"No BS beyond this point"
Yes, one of my projects had this sign up in the War Room. Basically it means everything and everyone in this area tells the truth, is open minded, team focused, loses the ego, and has each other's back.
 
Video Conferencing
For distributed teams that just can't be onsite. They really need to be kept in the loop with constant visual and auditory feeds as much as possible in the War Room or general workspace area.

Whiteboard
Do I really need to say more?

Round Table and Comfortable Chairs
Yes sometimes Scrum Teams do sit down. Make sure it's not on back-breaking pine boxes. And always use a round table; there are no heads of the Manor here.

Kill Switch
In my book, the kill switch is used when people come into the room and disturb the team too much. Stakeholders are of course welcome, but once they begin to create anti-value, the Scrum Master needs to step in and ask them politely to please return another time as the team is busy "maximizing value" at the moment.

Short and Sweet
Don't drag meetings on. Make them short and sweet and just enough time to deliver a valuable result.

Clever collaboration tools
Trash the email and replace it with tools such as Slack or Skype for Business. They are better collaborations tools. Email is slow death to Scrum Teams.

"To know thy enemy is to know thyself." - Sun Tzu  
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!

Burndown charts are a great visual way to track the remaining work on a Scrum project. You can track story points completed to get an indication of how your velocity is performing, or effort (in hours usually) to see how your expected completion date compares to your actual/probable one.

Burnup charts are used for a similar purpose, but they hold a key advantage over Burndown charts that not everyone new to Scrum/Agile is aware of. Personally, I love to use Burndown charts because my brain seems to be wired to see project work reduce over time, rather than see it start at zero and build up (with completed points) over time. Nevertheless, I have to concede that Burnup charts are a better tool and I will show you why.

Here's an example of a typical Burndown char:



You can see from the graph above that our project started with 100 story points, and that we expected (blue line) the project to be completed after 10 Sprints or iterations. Or in other words, around 10 points per Sprint. Our Velocity is therefore 10. The actual Velocity (red line) however tells a different story. We can see that is traveling slower than the expected target. In fact, the project completed after 12 Sprints.

Notice Sprint 7. The red line is almost flat. This can only mean that something happened during the Sprint to make the team slow down their Velocity. But what could it be? Did a team member go on holiday? Was someone sick? Did the Product Owner dump a bunch of work on the team which they accepted? Did the team come across a technology problem? Was the Scrum Master unable to remove an impediment to the team? Were there too many distractions from stakeholders? Was the estimation of stories not realistic? Perhaps the team just didn't fill in their completed stories yet?



This chart still tracks points and velocity, giving us the same information as the Burndown chart. However, notice the green line?  That is the scope (number of story points etc.) in our Scrum project. During Sprint 7, a further 10 story points were added to the project.

Remember that our Velocity was 10? Well, assuming that the team has done 10 points again during this Sprint (so on target with their Velocity), on a Burndown chart, this would have been displayed as a completely flat horizontal red line, even though the team did the same amount of work.

Both burndown and Burnup charts are great for the team to track their progress; burndowns more at the Sprint level, and burnups more at the Release level. However, Burnup charts are still great at the Sprint level.



We can see from the graph above that the team did very little for the first couple of days, and then picked up steam in the next few days to complete 38 story points worth of work. Notice the red scope line didn't change, but it could have, and we would have been able to see if very clearly. This information can be compared to existing Velocity and even placed on the Release burnup/burndown graph alongside points completed and other metrics.

So does all this mean throw away the Burndown chart and replace it with the Burnup chart? Well, not exactly. The Burndown chart has its place, and as long as you don't need to visually display if a slowdown in Velocity was due to an increase in scope, then a Burndown chart is fine. Yes there are Burndown charts that display histograms with bars that fall below the X axis. I personally can't stand these as I am old school; what is above the X axis and to the right of the Y axis stays there.

Given that OCD stipulation, the Burnup chart is in my view the best visual tool between the two.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!

 

The Agile Manifesto has four values. A crucial one is that we value "responding to change over following a plan". This statement could well be misconstrued as meaning if you had a choice between change and planning, then go with change and forget about the planning. However, this could not be further from the truth.

Planning does occur in Scrum projects, just like in Waterfall. In fact, there is generally more planning done in Scrum simply due to the iterative nature of the work. There are planning/feedback sessions at the beginning, during, and end of each Sprint. When you add these sessions up, the total time spent is quite often more than what occurs during the upfront planning process so indicative of predictive lifecycles.

There are various levels to planning Scrum projects such as Project-level planning, Release-level planning and Sprint-level planning. Today we take a closer look at Sprint planning.

At the beginning of every Sprint, we set aside a planning session of no more than 4 hours per 2-week Sprint. The Scrum Master makes sure that the Scrum Team is present, and usually through the Product Owner's assistance with stakeholders, ensure they too attend the meeting. So, assuming that everyone who should be at the meeting is at the meeting, we can go ahead with our 5 steps to effective Sprint Planning.

1. Bring the Update
Before you even begin Sprint planning, there are two important items that you need to have. The first is the latest Product Increment, and the second is the updated Product Backlog. You must be sure that the Product Backlog was refined during the previous Sprint because Sprint Planning is not the place for Backlog Refinement, although some Scrum Teams still follow bad practices because they left it too late. Any user stories (or items) that were added, deleted, split, reprioritized or risk adjusted in the previous grooming session should have been updated in the Product Backlog.

2. Discuss, Negotiate, Decide
This is where an engaging discussion takes place regarding the remaining items in the Product Backlog. The Product Owner will have their own agenda (maximize value for the customer), while the Development Team take that into consideration along with their known capacity and begin to select the stories for the current Sprint.

3. Sprint Goal
Every team needs a goal right? Scrum Teams are no different. They develop a shared understanding of why they are going to performing the items selected for this Sprint. I like to think of the Sprint Goal as a contract of commitment within the team, for the team, and by the team.

4. Sprint Backlog
Once the Development Team decide what stories to include in the upcoming Sprint, this becomes part of the Sprint Backlog. It is a sub-section of the Product Backlog, not a separate document. It is important to remember that only the Development Team owns the Sprint Backlog. Not even the Product Owner can change it. The other part of the Sprint Backlog is the plan on how to get the work done by the end of the Sprint. This is one of the most important parts of Sprint Planning, because it will determine if the Sprint Goal can be met, and if the Definition of Done will be realized. Negotiation takes place again, and this stage can become quite heated, because the members of the Scrum Team may have very different views what "Done" means. Therefore, the Definition of Done is perhaps the single most crucial element during this meeting. Without a clear understanding and agreement of the DoD, the Sprint is more than likely gong to fail at the Sprint Review gate.

5. Process Improvement
At some point we need to factor in the improvement initiatives agreed upon during the previous Sprint Retrospective. These improvements, while not as crucial as the product increment perhaps, are still an important part of the Sprint, and in my view should be included in the Sprint Goal. While the details of the process improvement may have already been decided during the last retrospective, the Sprint Planning meeting provides a great opportunity to quickly summarize what continuous improvement initiatives the Scrum Team will strive to achieve during this Sprint.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!

 

Well I did the almost impossible, and proved that it is indeed possible. After getting audited for the PMI-ACP exam, I missed out on the exam cut-off date at the end of March 2018. This meant that according to many in the know, it would be necessary to learn the entire Agile Practice Guide in addition to the other recommended resources.

I decided against this, and in true Agile fashion, instead focused on what I believed would be "barely sufficient" to pass the PMI-ACP exam. I knew that in this way, if I did pass the exam, that would be the best indication of a true Agile mindset. And so, this is how I did it:

First a disclaimer. I am not condoning this method as the best way of passing the exam. Naturally, arming oneself with all the knowledge at your disposal would be a sensible thing to do. The Agile Practice Guide is one of those knowledge assets that is key for most people to pass the exam, and will undoubtedly become increasingly important as the years go by. I can only say what worked for me.

Step 1
First and foremost, I ordered a copy of Mike Griffiths book "PMI-ACP Exam Prep". Then I read the book from cover to cover without answering any of the end-of-chapter quizzes. Then I read it a second time (skipping the parts I was proficient in) and this time made sure to do the end-of-chapter quizzes. If you get around 80% average for these quizzes, then move on to the next step; otherwise go through the book again. I averaged around 85%.

Step 2
Look at all the "Tasks" for all seven domains in the PMI-ACP Examination Content Outline. It's a good indication of the kinds of topic areas and terminology that will be tested during the exam.

Step 3
Get a top-quality exam simulator. In my view there are only two: Fastrack and Prepcast. I went with Fastrack because it is aligned with the Mike Griffiths book. I only did two full-exam simulations. Yes you heard me correctly. Memorizing simulation exams is not going to reflect actual results in the real exam. It's far better to study hard and then attempt a simulation exam to get a true indication of your knowledge level. You should not get less than 70% on your first try, 80% on your second try and so on. I got 82% and 90% respectively.

Study Duration
I would say that I studied for around six weeks, for a few hours a day, and sometimes more on the weekend. Minus two weeks during the audit process when I didn't feel like studying at all.

Exam Day
Apart from a lot of noise in the examination room, some guy typing heavily on his keyboard (must have been for a different certification), people coming in and out of the room all the time, and the person who was coughing up a lung, hey it was fairly quiet.

Now for the shocking part. The exam was a lot harder than I thought. I have to say that 1/3 of the exam (around 40 questions) I was pretty unsure of the answers and just did my best to guess what I felt was correct. From memory, there were no questions on XP, only a few on Scrum, and a lot of focus on risk, stakeholders, team performance, and value delivery. Every exam is different, and perhaps on your exam you might get ten questions on XP.

You know how they say that you can usually cancel out two answers on the exam and be left with two seemingly correct choices, and then just pick one? Well I recall well over 20 questions where I could swear three of the answers could have been correct.

One of my colleagues here on PM.com said he was out of the PMI-ACP exam in 1 hour. Either he is a super computer, or we had two totally different exams (I'm skipping the third option where I am just plain dumb). I took around 2 hours and then went over some questions again before ending the exam. I probably wasted 30 minutes not being able to focus due to the noise in my examination room. I am totally OCD that way.

When I finished the exam, I honestly had no idea how I went, and was nervously anticipating the worst at the end of the survey. Instead, I passed the exam with "Above Average" in each of the seven domains.



In summary, I have to accredit the PMI-ACP exam pass to the Mike Griffiths book and by association, the Fastrack exam simulator. Not to mention my perseverance, beeline focus, and a strong cup of coffee just prior to the exam.

It was a rocky road, but at the end of the day, I am still happy to be certified as an Agile practitioner with the world's leading project management and Agile certification body, PMI.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!


 

Earlier this month, I coined the term "Scrumian" to mean any advocate of Scrum. However, I never really thought about what it means or what it could mean. I have been giving it some thought over the past few weeks and came up with a very basic framework to define what a Scrumian is or should be, and I certainly welcome any suggestions for additions or improvement. After all, what kind of Scrumian would I be if I didn't entertain the idea of continuous improvement, iterative feedback, and maximizing value.

Most people enter the world of Scrum through their employment, or through the need to gain qualifications in the hope they will add some value to their job or future employment engagement. They sign up for a course, take it in-class or online, and then study toward any number of certifications such as the PSM, CSM or SMC. One thing binds them all; they adhere to the values and principles of Scrum. They also acknowledge and respect the rules, roles, events and artifacts of Scrum.

By doing this, they can become valuable assets to their employer or client and look with pride upon that shiny certificate hanging on the wall. In most cases, this would seem to be a complete success story; one that has come full circle. But is it a success? To the Scrumian, it is only half the (user) story.

The Scrumian Philosophy (Draft Zero)

A Scrumian not only adheres to the principles of Scrum in the work environment, but does everything they can to promote and "radiate" Scrum throughout the world. That means we extend our knowledge and skills into society in general, through our hobbies, our volunteer work, our children's education, our pet projects, heck even our personal lives if it adds value.

We promote Scrum through the technology and communication mediums we have at our disposal. Blogs, articles, books, podcasts, social media pages, chat forums, study groups, tweets, best practice centers, focus groups, and the list goes on.

For all the reasons we became advocates of Scrum in the workplace, is the same reason we believe Scrum can alter society and our personal lives for the better. From a simple Daily Scrum at home to see what the family did today and will do tomorrow, through to promoting information radiators and estimating with story points at the local YMCA.

I call on all Scrum advocates to go beyond their certifications, beyond the clock-on and clock-off usage of Scrum at work, to embrace all the richness that Scrum has to offer, and radiate it throughout the world.

We are Scrumians!
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!