Monday, December 26, 2011

Scrum : How to accommodate the infrastructure tasks at the beginning of the project?

Anu is a new scrum master. After the project kick off meeting on further discussion she realized that for a successful delivery as a pre-requisite the team needs a lot of infrastructure work to be completed. PO wanted the feature development work to start as soon as possible. Team had serious concerns about the delivery if they start the actual work without the required infrastructure.

What can be done in this situation?

I met with Anu and we agreed on the following

Identify the most critical requirements required for the team to start work. Do a casual analysis with the subject matter expert and the team and find the cost (duration + software + hardware costs) of doing (and not doing)

Anu held meetings with the team, PO & other stakeholders. This teamwork produced a wonderful infrastructure backlog and was presented to PO. She also added the dependency to this backlog. Nice to have infrastructure were at lower priority. This infrastructure work was added to the first two sprints. Team was also asked to do a sample application integrating all the infrastructure work as part of sprint backlog. With this sample application team validated the infrastructure configuration. The other infrastructure woke like server to do load testing; performance profiling was added to the middle sprints.







Saturday, December 24, 2011

Scrum Sprint duration – which is ideal; 4 weeks or 2 Weeks or 1 Week? Checklist


The CTO heard about SCRUM. He asked the PMO to implement it. We got a big training. Everyone is happy. We know everything about scrum- product backlog, sprint backlog, daily scrum, sprint review, retrospective. Wow so cool. But no one told me the duration of a sprint. How can my trainer not know about this? This seems familiar? There should be many yeses.
There is no definite duration for sprint !!!
Ken Schwaber & Jeff Sutherland started the sprints with 30 days duration. Now majority of the companies prefer 2 week sprints. If you don’t have any idea; start with 2 weeks. After the couple of 2 weeks iterations get together with the team, collect their feedback and decide whether you want to change the sprint duration. Personally I have seen teams with sprint duration of 20 days, 15 days, 2 weeks & even 1 week (I have my two teams running on 1 week).

Checklist for sprint duration change.
Reduce the sprint duration
  • Poor estimation (if team complains that they work for 8 hours on the task estimated for 4 hours) 
  • Poor quality (lot of bugs & performance issues) 
  • Unable to meet the sprint objectives  
  • Lot of scope creep 
  • Nature of deliverables (if the team is responsible for the delivery of small reports or documents which won’t take more than couple of days) 
When the sprint duration is reduced team will meet more often for planning and review. This will help in better planning, estimation & understanding of sprint objectives. PO will also have a better time managing all the changes in the backlog due to frequent changes in customer priority.
Increase sprint duration
  • Product backlog is almost stable  
  • The inability of the customers/PO/stakeholders to meet periodically to review the delivery 
  • Nature of deliverables (some deliverables need long time to develop, integrate & test)

What is scope creep? How can we prevent it?


I have faced this many times. Due diligently I follow the requirement documents and create software. But on many occasions testers/customers will discover new requirements from the existing ones. They may be doing this with right intention but imagine the waste when we have to continuously redo our work every time. Apart from the rework imagine the chaos it can create. If this creates so many problems, should we completely prevent such changes? Never. Software should be adaptable and extensible enough make such changes without adversely affecting other areas/features.


There should be a mechanism by which we should allow these changes to happen but in a controlled manner. Scrum has a definite answer to this problem.


As long as the "creep" doesn't happens during the sprint its fine. Once the items for a sprint are finalized then nothing else should be added. The sprint demo should happen only on the items which were agreed during sprint planning & only on the conditions of acceptance defined. If anything new is found during actual sprint execution or during sprint demo, then it should be noted down and added to the backlog. PO can prioritize these new changes for the team after discussion with the stakeholders.


SCRUM- Who should write a user story

Traditionally user stories (or requirements) were written by Business analysts. They used to prepare big documents after months of study. It was a herculean task. I used to get such UI/Functional specification documents. I have fixed a lot of bugs because I missed few text in such 1000 + pages document. This is not the only interesting part. Some of the requirements were so weird that I often wondered why I am creating the features which no one is going to use. If I had the option I would have recommended a better option. If the BA’s misunderstood some requirements & customers failed to correct those few words in the epic requirement then we will have a nice situation.

In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes
In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s... anyone can update this but ultimately it is the PO who is responsible for the backlog.
User stories should be written in a non -technical manner from the perspective of an end user
e.g.
As an x user I should be able to xyz actions.

This user story will be further sliced. The PO (or story writer) shouldn’t spend months is defining the backlog. After fine tuning the stories to an extent this should be put to review to the scrum team. The entire scrum team should work on these stories to understand it perfectly. Any technical constraints /limitations should be noted down & presented to customer. Scrum emphasizes this team work. It’s better to have 5 brains working together than one. The most important section out of these discussions/workshops will be the condition of acceptance (COA’s). Generally these COA’s are not technical. NFR’s can be added as constraints to these conditions.