, , , ,

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.

What?

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

Why?

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.

Who?

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.

When?

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).

How?

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.

Elaboration:

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.

, ,

New to Agile?

In short, agile and lean are general concepts, the former basing on Agile Manifesto and the latter on Toyota Production System. Then we have Scrum or XP, built over agile, and Kanban, built over lean, which are specific methods teams can implement, like Prince2.

Personally, I don’t treat agile and lean movements in a very orthodox way — they base on the same principles. So, to some point, they’re overlapping. Also, you will find teams mixing methods from both houses, Scrumban (a combination of Scrum and Kanban) being probably the most common.

If you wanted to position agile/lean methods somehow I’d say that:

  • Scrum is the closest to the old-school project management methods, although it doesn’t really deal with formal side of project management.
  • XP focuses on engineering practices and is generally programmer-centered.
  • Kanban is often dubbed change management framework as it doesn’t change the way team works on the day 1 and lets the process evolve over time.
  • As all three focuses on different things, it isn’t uncommon to see them, or their parts, used jointly.

If you want to learn more I’d start with such set of materials:

  • Introduction to Scrum on Mike Cohn’s site. If you want more on Scrum Mike Cohn’s site is a good place to find also more advanced stuff on Scrum.
  • Once you know what Scrum is I’d strongly recommend Henrik Kniberg’s and Mattias Skarin’s minibook Kanban and Scrum – Making most of both which is great in terms of describing Kanban but has a lot of referrals to Scrum.
  • For more advanced stuff on Kanban I’d recommend Limited WIP Society articles (topic for my next blog).
  • Good kick start on XP can be found on Ron Jeffries’ site.

In terms of books as a kick start, I’d recommend:

  • Mike Cohn’s Succeeding with Agile for Scrum
  • Kent Beck’s Extreme Programming Explained for XP
  • David Anderson’s Kanban for Kanban

If it is too much of a hassle to read these books and digest then contact us and we may be able to help you.

, , ,

Agile Learning and Seeking Knowledge

India’s Mars Mission

2013-11-05 09.23.07

A proud moment for every Indian as rocket lifts off from Shriharikota (South India). A massive step towards learning about red planet. This news prompted me to consider the current and future role of learning activities undertaken by people and organisations. Learning is acquisition of new information through practice or experience[1] and it occurs in response to a need or problem.

2013-10-25 18.55.17-1

During my MBA lesson at MBS Manchester, professor Norman Longworth describes the stages in human learning as “Information Ladder”. According to the ladder, a learner moves through the following progression to construct ‘wisdom’ at the highest level from ‘data’ at the lowest level:

Data -> Information -> Knowledge -> Understanding -> Insight -> Wisdom

Whereas the first two steps can be scientifically defined, the upper steps belong to the domain of psychology and philosophy.

According to Sherry L. Willis, a renowned researcher from US, long-term learning activities is the ability to acquire and retain relevant information and to solve problems. Problem solving involves assessing the present state, defining the desired state, and finding ways to transform the former to the latter. Decision-making refers to the evaluation of possible solutions and the selection of one for implementation[2].

A major difference between experts and novices is in their possession and use of two forms of knowledge: declarative and procedural knowledge. Declarative knowledge involves knowing what facts and information are relevant in solving a particular problem[3] .It is one’s knowledge of the subject matter. Experts have the ability to select quickly the most relevant information for a particular problem, obviating the need for a more exhaustive and time-consuming search through their declarative knowledge.

Procedural knowledge represents the individual or organization’s understanding of how to go about solving a particular problem—how declarative knowledge relevant in a particular situation can be combined to produce a solution[4]. Often the procedural knowledge involves performing a set of operations or following an algorithm.

Individuals and organizations that are new to Agile and Lean may spend much time developing or discovering a plan as they go about solving a problem. An agile expert is quick to develop an appropriate plan to use relevant information and solving a particular problem. The expert “plugs in” the relevant information to the plan or script which helps you to gain knowledge and apply with greater efficiency.

Please contact us and see how our experts can help you and your organization with learning Agile and Knowledge Management .

REFERENCES

  1. Howard and Howard, 1997
  2. Reese and Rodeheaver, 1985; Reitman, 1964
  3. Anderson, 1985; Chi, 1985
  4. Anderson, 1985; Chi, Feltovich, and Glaser, 1981
  5. Rogers, 2000