Skip to main content

Posts

Showing posts from December, 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 s

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 hou

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 con

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 up