Follow the I4 Process Blog

 Subscribe in a reader

Enter your email address:

“At Palmchip, where I was VP of Marketing, Shelley was able to use her experience along with her knowledge of core marketing processes to keep our project on schedule and meet budget targets. She is articulate in explaining both her methodology and its benefits to high-level executives, as well as to managers and staff members. This is a key to obtaining early and complete buy-in, which, in my experience, in critical to the success of a project.”

MJ
Vice President
Palmchip

 

Three Ideas from Scrum for BPM

I took an excellent Certified Scrum Master course from Jeff McKenna, President of Agile Action, about two months ago and have been using many of the concepts and techniques for my weekly work, especially about writing my new book Process Improvement Making Projects Simple, Structured, and Successful (to be published about March of 2014). The Lean philosophies are not new to me but I found my project work could use some fine tuning.. Here are three things that continue to help me and would help in Business Process Management projects.

Time boxing:  In scrum the time boxing period (called a Sprint) is one week to two weeks. The team determines what is going to be completed from the Product Owner’s product backlog (or needed product requirements) in that time.  That means that deliverables are sized to be completed in the spring time frame. Once the agreement is made, there can be no scope creep.  Instead new requirements go in future sprint. The scrum project team reports on their completions against their estimate in the Sprint Review with a discussion of how to do differently next sprint. The next sprint is a fresh start, but the time frame is boxed and starts right up again.

I use a time boxed period between workshops when doing a business process improvement project.  It does not have the rigor of a Sprint, but it has the movement, and the needed adaptiveness. It also pushes the team to stay away from analysis paralysis and maintain progress toward the final improvement targets.

User Stories:  As Jeff states, user stories

  • Are simple descriptions of the desired functionality
  • Have clear acceptance criteria and are sized for planning

The template to write a user story is: 

As a <user role>
I can <do something>
So that <I get some value>

Here’s an example for my book:  As a reader, I can determine if this analytical technique is needed, so I don’t waste time on unnecessary analysis.

I have been writing user stories to drive toward the completion of my book.  The Product Owner (me in this case) defines what functionality needs to be completed.  I have a backlog of about 20 specific user stories. I identify which ones I will  complete in the next sprint (here I am acting as the Scrum team).  Each story I  write I do a better job of defining the acceptance criteria.  My initial chapters were ‘finished’ but they really weren’t finished because I had graphics left out, sections unwritten, or additional cases to include. Once I clarified the acceptance criteria I finished them vs. leaving several open items.  Now as I take work from my editor, I have new acceptance criteria at the next level of completion, such as reorganizing revisions for chapter 2 or getting permissions from a source. 

User stories can help in BPM implementation by designating the prototype output needed at the end of each sprint and having the Product Owner define the acceptance criteria.  Estimate how many stories can be completed in one sprint and keep the rest in the backlog.

For BPM implementation, a user story for implementing a new hiring process could be:

As a hiring manager, I can see the top ten candidates resumes online, so that I can select which ones I will decide to interview.

Estimation Basics: Estimates are not commitments; they are just estimates. The team takes the user stories it will work on and estimates them as small, medium and large tasks using a 1, 2, 3, 5, 8, 13, 21, etc. scale.  Then they figure out how many they can get done. Maybe two 5’s, one 13 and one 8. And you can do no better than yesterday’s weather.  That means if yesterday’s weather was slightly sunny the best estimate of tomorrow’s weather is slightly sunny.  Or for project estimation, if the team did 5 user stories last week, the best estimate is that it will do 5 the next week, although size can make a difference as well.  I found it simple and I only spent  a little time figuring this estimate; a team can choose their user stories and do estimates in a half hour probably.  For me, as the sprints went along I kept focusing on those user stories.  The goal is to meet acceptance criteria of the agreed user stories.

These are wonderful project management techniques for estimating, completion, and adjusting.  And it’s easier to get better at each element.  I found having estimated the number of  clear user stories really kept me on track.  The same can be true of implementation in a BPM project– the team complete user stories in sprints towards each prototype.     

Be Sociable, Share!

6 comments to Three Ideas from Scrum for BPM

  • I have also agreed on the synergies between BPM and Scrum in managing BPM projects. I believe that the fundamental principles of Scrum fit perfectly with bpm methodology and Scrum can providencia agility, speed and client oriententation.

    I have also write about BPM and Scrum in my blog, but it’s in spanish:
    http://bpmwasabi.blogspot.com.es/2013/09/bpm-y-scrum.html

    I wish you all the best with your book.

  • I have also agreed on the synergies between BPM and Scrum in managing BPM projects. I believe that the fundamental principles of Scrum fit perfectly with bpm methodology, and that Scrum can provide agility, speed and client oriententation.

    I have also write about BPM and Scrum in my blog, but it’s in spanish:
    http://bpmwasabi.blogspot.com.es/2013/09/bpm-y-scrum.html

    I wish you all the best with your book.

  • Kim Trivedi

    Hi Shelley, I was drawn to this post because I’m also a big fan of the Agile methodology. As a business analyst, I prefer writing requirements in the user story format to help bridge the communication gap that sometimes exists between the business and scrum teams. Defining acceptance criteria is also extremely useful to ensure all parties involved understand the expected outcome and what’s needed for UAT to pass. I also like the frequent communication and assurance that there’s a team full of skilled people who can help dogpile on a blocker if needed.

  • Nikole Hobson

    I really enjoyed the format of this blog. It was useful to see the scrum steps broken our into 3 individual parts: Time boxing,User Stories and Estimation Basics. Since the bulk of my work is with projects, project managers and architects that support these projects it is good to lean process guidelines broken down in terms of project management which is easy for someone from my background to relate to. I also liked the template to write a user story is which I listed below. A reminder of the correct language to use for BMP is always appreciated.

    As a
    I can
    So that

  • Ankur T

    This is a great article. The analogies used in article to explain Scrum methodology clearly explains the essence of it. I believe that Scrum methodology will work perfectly in BPM projects and can help speed up the project’s completion. I have a question about the user story mentioned about “New Hiring Process”:
    Wouldn’t it be better to include the criteria to select top 10 candidates in user story? Current user story doesn’t provide any business rules to Developers about how to determine the top 10 candidates for the job.

  • Grant Singh

    Excellent ideas from agile that can be leveraged for traditional/waterfall projects. I try to get the project team engaged in developing the Work Breakdown Structure (WBS) for all my projects. Adding time-boxing at the WBS stage would help project teams see the project in terms of manageable pieces and how these pieces fit together. It would further help team members appreciate their contribution towards the end product. Another challenge on projects is to train project SMEs to think in terms of acceptance criteria. Functionality descriptions are often written well at the requirements stage, but emphasis on the acceptance criteria typically comes in later stages. Using the proposed template is a good tool to establish acceptance criteria early, which in turn can be used to drive test cases and successful project delivery indicators.

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>