Red Hat

Most often, I see the teams get cold feet when writing user stories as they are not sure if they are getting it right. My usual response is that there is no perfect user story and that he purpose of user story refinement is to ensure that each user story has sufficient detail so that it can be programmed, tested, and integrated within a single sprint.

User story refinement increases efficiency of the team by greatly reducing risk by quill minimizing the unknowns. Having a adequately refined backlog greatly reduces the time required for a Sprint Planning meeting as all the team is able to have common understanding of the development that will be undertaken.

Always start by identifying thin vertical slices of work that can deliver business value. For example if a user login functionality has to be developed, the deliverable would need to have User Interface, Application logic and database tables. As opposed to developing the complete data model in the first sprint, application logic in the second sprint and the UI in the third sprint.

Typically it is recommended to work through enough backlog items that would last about 2 Sprints beyond the current sprint. This is to ensure that the team can still function if the Product Manager or Product owner are unavailable for a week or two.

As a prerequisite, ensure that the backlog is ordered to reflect the business priorities specified by the Product Manager or Product Owner. This will ensure we work on the user stories that have high business priority and need to worked on relatively soon as opposed to later.

User story or an epic? the best way to address this question is to follow the rule of thumb, which is if a user story cannot be completed in one sprint then it has to be split into one or more stories.

It is also a good practice to check if there are any internal or external dependencies for a particular user story and capture the dependency. This will greatly help during the planning session when the team is committing to a bunch of user stories.

Finally, almost all user stories require acceptance criteria, wherein one will specify when a user story can be considered completed or done and working as intended. This will also guide the Test and QE teams members of the team to appropriately write test cases.

Hello Folks, I have been meaning to blog on the subject of Agile and Scrum because most of the material available today focuses on simplistic implementations such as co-located teams. Also they assume a simplistic predefined structure wherein the stakeholders are identified and available at the team’s discretion and dependencies could be worked out within one or more teams within the organisation.

The complexity is compounded in open source projects because of the varied nature the intermingling of contributors and stakeholders. The team is not only focused on features that were loosely drawn up by the product manager but also works actively on the ones that the community is interested in.

I also hope to address some of the challenges that are unique to working in open source environments, wherein you have to collaborate with not only internal teams but also work with external organisations which sometimes have conflicting interests.

One of the focus areas will be working with globally distributed teams, wherein the team members are spread across different timezones. For example even a simple thing as daily standup becomes challenging due to time zone issues making it impossible for team members to meet at same time.

If you are wondering about the image depicting lightening in a bottle – Well the original expression is “like trying to catch lightning in a bottle”, it describes something that’s extremely difficult, almost bordering on the impossible. That is how I feel, my self imposed assignment would be like, but based on the amount of pain and confusion it can alleviate, the effort will definitely be worth it.

Over the years I have realised that we tend to learn better from short, focused articles rather than elaborate descriptions and detail material. Hopefully, these one-pagers will aid in understanding and adoption of Scrum.

So, the plan is as follow up with short one pagers, in the context of open source and globally distributed teams.

scrumosa

Snack Sized Agile Learning

There is no perfect user story so let’s get started already

Scrumosa – One pagers on Agile & Scrum in Open Source