>
Showing posts with label Sprint. Show all posts
Showing posts with label Sprint. Show all posts

Sunday, March 2, 2014

Impediment v/s Bug - are they same or different?

Let's understand what is impediment and bug in Agile Scrum. First of all they both are not same, they may be distantly related in some special situations but they are different.

Here are the basic definitions:
An impediment is a situation that is stopping/blocking the completion of work.
A bug is referred to a defect or issue in the work product.
On side notes do you know that the word "bug" was used to indicate an actual bug (fly, moth) on a circuit board causing a short-circuit or other problems. You can read more details here - http://theinstitute.ieee.org/technology-focus/technology-history/did-you-know-edison-coined-the-term-bug

A defect would typically NOT block the completion of work, though in some situations a defect may impede work and also be am impediment at same time. For same reason, a defect would relate to implementation of a work item (user story), where as impediment would block one or more work items (user stories).

Defect and impediments are tracked seperately in defect tracker and impediment tracker. Bugs would eventually be prioritized and added to product backlog and re-prioritized by product owner. Impediments would never be added to product backlog, but resolution of an impediment may be taken out as spike; if some research work is involved and/or a major bloker to work.

While bugs can be identified during development activities (coding, testing etc), and impediment would typically be identified during daily scrums. The scrum master is responsible for helping resolve these impediments to improve team productivity.

Friday, February 28, 2014

Sprint velocity basis yesterday's weather - Agile (XP)

Ok, before we understand what is 'Yesterday's weather' in Agile, let me tell you that Yesterday's weather is not an agile scrum term but an extreme programming term. Some of Agile terms are used interchangably now a days, and this is one of the methods to estimate sprint velocity for upcoming sprint, so thought to cover this term.

Lets take this example -
if it has been raining yesterday in Delhi, then it's quite likely that it would rain today as well. It may not be 100% accurate forecast but still good enough to suggest someone carry an ambrella today.

In Agile, 'yesterday's weather' refers to last sprint's velocity. Development team may have been working at varying velocity in past sprints (20, 18, 25, 28) so one of the ways to estimate how many story points development team can deliver in next sprint is to check last sprint's velocity - this may not be the best way but can be called a best guess, or bet. So in this case, 28 story points would be the answer.

You may also find these related posts valuable in Sprint Planning section.

Wednesday, March 6, 2013

Scrum Events Timeboxing


All the events in Scrum are timeboxed and here is the list of key events and their timeboxes -
  • Sprint (also called as iteration) - 2 weeks (or as planned - between 2-4 weeks)
  • Sprint Planning Meeting - 8 hours*
  • Sprint Review - 4 hours*
  • Sprint Retrospective - 3 hours*
  • Daily Scrum Meeting (also called as Daily Standup) - 15 minutes (fixed regarless of sprint time)
* - time box given here is for a four week (one month) sprint - to be adjusted depending upon the sprint duration.

What Product Owner is busy with during Sprint?

Though Agile Scrum has just three roles - Product Owner, Scrum Master and Developers, but the roles and responsibilites of each one can be very confusing at times. One of the most frequently asked question is "what activities a product owner engage during sprint?"

Answer: When sprint is in progress, Product Owner would usualy be busy grooming prodoct backlog, answering queries from development team (if any), talking to stekholders (dont forget- he is adding new items to product backlog, re-prioritizing items etc....so he needs to talk to stakeholders), and may help with some early testing and provide feedback as well.

Saturday, March 2, 2013

Timeboxing v/s Parkinson’s Law

Lets understand the connection between Timeboxing and Parkinson's law -

1) According to Parkinson’s Law - "work expands so as to fill the time available for its completion". What that really means is that a worker will drag the work to use up all the time given to him/her - even if he/she can finish that work ahead of time. So if a work is estimated to take 100 hrs and a worker has completed 50% of work in 25 hrs, he/she will still consume all 75 hrs to finish remaining 50% of the work.
2) Timeboxing suggests to fix 'time to completion' for the agreed upon Sprint goal and the Sprint will end at fixed time (hence term 'time boxed'), so the developoment team moves together to achieve the Sprint goal within given time period.

Sprint v/s Iteration

Lets understand the difference between Sprint and Iteration in three easy steps -

1) Iteration is a generic Agile term that is used for any process thats iterative/repetative
2) An iteration in Agile Scrum is called a Sprint
3) Other Agile variants may or may not use same term to define iterative work, but these two are most common terms in use