Posts

, , , ,

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.

 

, ,

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.

, ,

People arriving late to Standups/Scrum Meetings?

I have seen many Scrum Teams have trouble getting to their Standup on time, and being properly prepared. My suggestion is to get hold of some kind of “cheap simple noise device” (eg bell, hooter, drum, cymbals; NOT a mouth-contacting whistle/trumpet/vuvuzela).

Step 1: Make the warning noise of your choice 1-2 minutes before the meeting starts. (and maybe another 1 when the meeting actually starts!) Many team members, especially the usual latecomers, hate this approach, but it is highly effective. Especially when you try

Step 2: After 1-2 Sprints, select 1 person (somehow) who is still late/latest to the standups, and give them the power of making the warning blast – make sure the team knows who the week’s/sprint’s “victim/cop” is, and make sure they know just how vitally important their new responsibility is. You even get to take the device over to them at the right time, just to help them if they need further motivation.

Step 3: Usually after 2-3 Sprints, everyone is at least getting to Standups on time. If all is excellent, you may wean (or not) away from using the “noise device” – depends on whatever team culture has evolved in response.

Happy Scrumming!!!!

,

Estimating Data Warehouse Project

I have always wondered what is a realistic expectation for the time to design and implement a data warehouse? I am managing a Data warehouse project in an agile environment where the key idea is to deliver business value frequently. The initial estimate to deliver complete DW was in 6 months which I was always felt was too short. There are few challenges with this project;

  • Team members were new to agile development with strong opinion about non agile delivery of DW
  • Legacy systems which has grown organically over a period of decade( partially documented)
  • Source system which was build using non English language
  • Key business decisions were being made using spreadsheets produced by few people

In a meeting with management, team committed to deliver this project in 6 months which I felt was bit ambitious. With the help of Google I came across few estimation techniques which I will be referring here. In any traditional organisation the CIO/CFO would be interested in knowing how long will it take and how much will it cost. It’s a chicken and egg kinda situation, Since the project is not approved therefore you cannot hire experts to estimates and without an estimate your CFO will not approve the project. In order to make life easy I decided to divide this problem into two parts:

  • Pre approval estimates
  • Post approval estimates

After some research I came up with the following simple tool( thanks to experts who shared their knowledge).

[ws_table id=”6″]

This will give you a high level estimate which can be used for approval from Project sponsors. Once project is approved, start building your product backlog (detailed requirements) then go through agile estimation process to come up with better estimates. If you need more information or want to organise a workshop to estimate your product back log the get in touch with sales team(Sales@capriconsulting.co.uk) and they would be able to help you in organising it.

Happy estimating

 

,

Is there a point in story point estimation?

Is there a point in story point estimation? How do we estimate accurately?

This is a relative size of the story compared to other story estimated by the same team – it has nothing to do with who is implementing it and how long it’s going to take. Story points are relative estimate, so that you know that 5 point story will take approx. 5 times longer than 1 point story.
Benefits are

  • Team’s velocity can be measured
  • Allows team to plan future sprint without over/under committing and forecasting total number of sprints. As a result no unrealistic expectations are placed on the team
  • Helps team to focus on completing dev and testing in the same sprint
  • Helps teams reach a sustainable pace and due to this the business starts to believe in the teamHours (or ideal hours) are more about time estimation. It can lead to several problems:
  • Your “hours” are not the same as mine. It can be harder to make team estimate during release planning.
  • It’s easier to make relative estimates and then calculate team velocity in points.
  • Stories are usually decomposed to tasks for the sprint. These tasks can be implemented by different people. So total effort is not simply calculated as sum of task estimates.
Usually it’s recommended to make story estimation in points for release backlogs and in hours for sprint backlog.
  1. Story points are a pure measure of size and complexity
  2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
  3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
  4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
  5. Story points don’t influence behaviour (e.g. Parkinson’s Law)
  6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
  7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.