, , , , ,

Top 10 Agile Transformation Quotes

These inspirational Agile Transformation quotes are from on-the-ground practitioners and speakers of the Agile community. We gathered top 10 most popular quotes to share here.

1. “ScrumMasters, please don’t touch the task board. It do not belong to you.” -Michele Sliger
2. “Big egos have little ears.” -Robert Schuller
3. “Listen, really listen to people who disagree with you in order to fight confirmation bias.” -Linda Rising
4. “Alignment enables Autonomy” -Henrik Kniberg
5. “it’s not a testing problem, it’s a design problem manifesting as a testing problem. usually.” -Kent Beck
6. “My advice is to stop emphasizing the Agile Transformation process frameworks and start focusing on the company culture and mindsets.” -Selena Delesie
7. “Every retrospective should be unique.” -Esther Derby
8. “Failure really just means that your system is trying to tell you something – so you’d better listen.” -Henrik Kniberg
9. “When the manager plays the role of ScrumMaster, it’s highly unlikely the Team will ever begin to self-organize.” -Pete Deemer
10. “Trying to speed project schedule by reducing testing is like trying to lose weight by donating blood.” -Klaus Leopold

Thanks to Kirill Klimov for sharing these quotes.

, , , , , , , , ,

Capri sponsoring Agile Manchester 2015

AgileManc_FullLogo_Colour_RGB_2015Capri Consulting are proud to announce their sponsorship of the Agile Manchester 2015 taking place in Manchester on 7 and 8 May 2015.  Whether you are new to Agile  or have more experience there is lots of interesting content for you with great speakers like Liz Keogh and Jurgen Appelo and 25 sessions, it’s going to be a productive 2 days!

We are very excited for the event to take place, as it is set to be a corner stone of the Agile industry for 2015. It is particularly exciting as Agile has been becoming more and more popular in recent years, with more and more companies adopting the Agile Methodology, of which we are advocates. Book your place now, as tickets are selling fast


Make sure you come and check out the Capri Consulting stand and collect freebies! See you in Manchester!!

, , , ,

Agile Tasking

Customer: I want to build a home. Could you give me an estimate?

Builder: No I cannot! You need to give me more information like how many rooms, plot size, how many floors etc.

Customer: I need you to build me a four bedrooms, two and one-half baths, a gourmet kitchen, walkout basement with media room and three-car garage in Pennsylvania.

Builder: Now you are talking! Do you insist on top-of-the-line cabinets and appliances for your gourmet kitchen, or will mid-range ones do? Are you planning to side the house with cheap vinyl or expensive stone brick? Is the house going to be one story, or two?  Will you have simple, rectangular rooms that minimize the materials and the labor required for framing, or unusual shapes like octagons with vaulted ceilings? What sort of flooring, bathroom fixtures and heating and cooling system will you have? Is the lot easy to access, relatively flat and easy to dig, or is it rocky, heavily wooded and uneven?

Similar to above story , its very difficult to provide an estimate when your customer asks the scrum team how long will it take deliver this feature or functionality. Breaking down the user story into tasks will help team to estimate their work accurately and track sprint progress.


Tasking is the process that the developers undertake to understand, design, and properly prepare to write code for a user story.


The challenging decisions are made during tasking.  If tasking is done properly then the actual coding is a much simpler task.  I believe that this is the most important thing any scrum team does.


It’s important that all developers and testers attend.  This serves multiple purposes.

  1. every developer on the team begins to become comfortable with the code base for all of their applications
  2. every developer has the ability to include their input on the design and solution
  3. any developer on the team should be able to pick up any story at any point to complete the tasks because they were there and the expectation should be such.
  4. every tester in the team can ensure they’re aware of the solution and that it meets all of their criteria.

It’s also good to have the BA there to review the story with the team and answer any questions.  Once the story is reviewed it usually makes sense for the BA to go about their day and to let the developers get into the technical details.


Second half of the sprint planning session or right before the work is to be done (if  other stories being implemented that may change the approach and invalidate the tasking that was completed).


Step 1: Review Current Code

The developers will review the current code that relates to the user story.  They will walk through the code to ensure that everyone is on the same page with what the code currently looks like.

Step 2: Decide on Changes to Code

The developers will discuss how to modify the existing code to make the addition of the new functionality simple.  It’s common for developers to perpetuate the logic found in the current code (good or bad), so always considering ways to change the code is a key to having well written code.

Step 3: Draw a Sequence Diagram

The sequence diagram is a visual representation of the classes that call each other to accomplish some discussed part of the code.  If this diagram is complicated, then it’s a great indication that the code should be modified so that the diagram is less complicated.

Step 4: Task Out New Work

Once everything is decided, the actual coding tasks should be created and ordered.  Each task should take under an hour to complete.  The developers can then grab these tasks and complete the story in small chucks in separate streams ( if needed).

Why Tasking Doesn’t Happen?

For all of the reasons stated above, it’s important that the teams task stories.  It’s easy for developers to take shortcuts and skip tasking.  One of the main reasons is a lack of collaborative areas.

Tasking can take developers 4+ hours, and they need a whiteboard, projector and computer to properly task.  Finding a room like that for 4+ hours is challenging at times.


, , , , ,

Difference between Product backlog Grooming, Sprint Planning and Elaboration

Difference between product backlog grooming, sprint planning and elaboration

Cancelled sprint planning meetings, frustrated team because there are not enough stories in the sprint, too many stories to deliver (feast or famine situation) are symptoms of poor planning and lack of discipline.  I usually take the following  3 steps to ensure smooth flow of user stories and high productivity.

Step 1: Pre Planning

Step 2: Sprint Planning

Step 3: Elaboration

Recent debate over value of these activities prompted me write this blog. To make things clear, I would explain each activity in detail:

Pre Planning (Backlog Grooming)

Who: Product Owner and team representatives

When: Mid sprint

What: Backlog grooming (also called maintenance or pre planning) is not a formal ceremony of the Scrum process, but it is advised that PO, BA and team representatives to dedicate 10-15% of every sprint to this activity. During pre planning, everyone helps prepare the scrum backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort( t-shirt sizing) for existing stories. PO identifies candidate user stories (based on priority) for next sprint planning and team representative helps PO to alter list based on technical feasibility.

Why: Groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the appropriate team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning always occurs prior to the sprint planning meeting.

Sprint Planning

When: In Scrum, every iteration begins with the sprint planning meeting.

Who: Product Owner and the team

What: At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. Time-boxed to two to four hours, this meeting is a conversation between the Product Owner and the team. During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog. PO to answer questions, clarify acceptance criteria, or renegotiate. Team sizes story in story points based on complexity and effort required. Stories are broken down to tasks and tasks are estimated jointly in hours. Estimation must be done as group as it varies from one team member to another according to individual’s experience. Scrum method encourages collaboration and reduces the risk of underestimating or over estimating any task.

There are two defined artifacts that result from a sprint planning meeting:

  1. A sprint goal
  2. A sprint backlog

Why: Helps Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments. This is a good thing since the team may be aware of a legitimate impediment keeping the team from moving forward. This helps team to work out their capacity, plan stories according to capacity and commit to a realistic target. Setting unrealistic target and not achieving it sends a negative signal to stakeholders and affects team morale.

Warning !!: Some teams may under commit and over deliver.


Who: PO, developer and tester

When: Each of these “levels” of requirements are addressed progressively at various points in the sprint. Usually before starting a user story. The product owner should be available for consultation if the development team needs further clarification on requirements throughout the day.

What: In order to actually develop a user story you need to consider several levels: Themes or Epics; Features; Stories; and then the nitty-gritty details associated with Stories. Progressive elaboration of user stories just means that big user stories are broken down into smaller ones and filled up with more detail when they appear closer to implementation

Why: Whenever the development team tackles a new user story, elaboration ensures that any unanswered questions about it are answered so that development can proceed. The product owner works with the development team to elaborate user stories, but the development team should have the final say on design decisions.

Hope this explains why we have various ceremonies and what value they add to the successful delivery of sprint objectives.

Keeping agile simple, pure and meaningful.

, , , ,

Estimating story from trenches

In today’s user story writing workshop my client asked me how do you estimate a user story?

To me, Complexity, Effort and Time are three key things we need to consider while estimating any user story. You look at the complexity of a story to derive the effort required to estimate the time it will take you to finish the story.

To use an analogy of carrying a log of wood from point A to point B:

COMPLEXITY: “How BIG and HEAVY is the Log of wood?”

EFFORT: “How much horsepower is required to pull this log?” This is where Story point comes in.

TIME: Say it takes 2 Horsepower, “how quickly can 6 horses move the log from A to B?” And this, we all know is velocity which can only be derived after a few Sprints.

Complexity cannot be seen in isolation and effort cannot be measured without knowing the complexity.

P.S. I can assure my readers that no animals were harmed in the making of this blog.