Learn Software Development » Sprint Meeting http://learnsoftwareprocesses.com All about the processes involved in software development Tue, 07 Feb 2012 19:53:10 +0000 en hourly 1 Does a smaller size of Sprint mean more overhead ? http://learnsoftwareprocesses.com/2011/11/15/does-a-smaller-size-of-sprint-mean-more-overhead/ http://learnsoftwareprocesses.com/2011/11/15/does-a-smaller-size-of-sprint-mean-more-overhead/#comments Tue, 15 Nov 2011 20:17:32 +0000 ashish http://learnsoftwareprocesses.com/?p=919 In the organization where I work, most of the Sprint cycles are 3-4 weeks long. When trying to determine the size of what a Sprint should be, most teams new to Scrum do not have any great planning process on how to determine the size of the Sprint cycle, and decide based on their talking [...]]]> In the organization where I work, most of the Sprint cycles are 3-4 weeks long. When trying to determine the size of what a Sprint should be, most teams new to Scrum do not have any great planning process on how to determine the size of the Sprint cycle, and decide based on their talking to teams that have actually implemented Scrum. This mostly works out to be 3-4 weeks long for the Sprint cycle.
In some cases, when the teams had started implementing Scrum and had spent some months at this, there was a query from a number of people in the team about why the team was doing a Sprint cycle of 3-4 weeks. If the group was involved in supporting other groups, then would not be it better for the group to go in for a shorter Sprint cycle, and maybe even evaluate a much shorter Sprint cycle, as short as 1 week. At this point, there were a number of positions in support and against the thought of reducing the length of the Sprint cycle.
One of the biggest objections to a reduced Sprint cycle was about the extra overhead that the teams would be subject to. So, consider the various planning meetings that happen, such as the Sprint planning meeting where planning and estimation happens, then the meeting where the demo happens, and also the retrospective discussion. Wouldn’t the team have to do all these meetings even when the length of the Sprint cycle was much shorter, and would they not consume too much time in relation to the overall length of the cycle ? After all, if these meetings end up taking around 2 days overall in the Sprint cycle of 4 weeks, when you have to do them for a much shorter sprint cycle of 1 week, the proportion of total time that will be spent in the Sprint cycle for these meetings will be far higher.
I don’t know what you folks think, but I do believe that this is not a correct supposition. If you are doing a much shorter Sprint cycle, the amount of User Stories you discuss will be lesser, and as a result, the amount of time you spend for these meetings will be much lower, and the same will be true for the demo and the retrospective. In addition, with a much shorter Sprint cycle, you will be end up being able to react to changes much quicker.

Book: Succeeding with Agile: Software Development Using Scrum

]]> http://learnsoftwareprocesses.com/2011/11/15/does-a-smaller-size-of-sprint-mean-more-overhead/feed/ 0 How to define tasks for a User Story without spending a fair amount of time on these ? http://learnsoftwareprocesses.com/2011/10/30/how-to-define-tasks-for-a-user-story-without-spending-a-fair-amount-of-time-on-these/ http://learnsoftwareprocesses.com/2011/10/30/how-to-define-tasks-for-a-user-story-without-spending-a-fair-amount-of-time-on-these/#comments Sun, 30 Oct 2011 18:56:46 +0000 ashish http://learnsoftwareprocesses.com/?p=910 We seem to find ourselves running into a fundamental problem during out Sprint planning meetings. Some of it is from our older methods, but partially it also seems to be a problem with the way we are using our Scrum processes. Consider the process before getting into Scrum. We would have a list of features [...]]]> We seem to find ourselves running into a fundamental problem during out Sprint planning meetings. Some of it is from our older methods, but partially it also seems to be a problem with the way we are using our Scrum processes. Consider the process before getting into Scrum. We would have a list of features defined and agreed upon by the Engineering and Product Management teams to be done in the defined product development time cycle. However, things were problematic when actually getting into the actual stage of working out the tasks for these features. Many of these features involved features that were not done before, and so it was required that these features be broken down into tasks, and the team leads were assigned to this purpose. It would take a matter of some time for the features to be actually broken down into a matter of tasks. The feature team would need to have a few meetings to discuss the feature, talk to the User Design specialist to understand the way that the feature would work, and then work out the tasks.
However, it would take more time to work out the estimates for the task, and in many cases, this was a matter of guesswork, since the work required for the tasks had never been done before; getting these estimates involved some amount of discussion. And once these estimates were in place, when the actual work was happening, these estimates did change many times (sometimes the User Design was different from the one initially considered, and in many cases, the estimates were actually different from the work that was needed to be done to complete the task). This meant that the total effort needed to complete a feature was different from the estimates; and this happened for many of the features.
Now, when we started using the Scrum process, this became an open question. For many of the major User Stories that were a translation of the major features, getting tasks broken down into the User Stories was a major effort by itself, and it was postulated by the team that earlier it would take so much time to break down the features into tasks, how would it be possible to do this during the Sprint Planning process ? It was somewhat difficult to answer this question, although we did some amount of planning on how to define User Stories in such a manner that they would be readily understandable and could be broken down into discrete tasks that could be estimated with some amount of accuracy. This took some time to actually happen, and there were many cases where the effort estimation did not match the actual effort needed for the tasks.

]]> http://learnsoftwareprocesses.com/2011/10/30/how-to-define-tasks-for-a-user-story-without-spending-a-fair-amount-of-time-on-these/feed/ 0 Scrum – When the Product Owner finds it difficult to attend the meetings (Sprint Planning, Retrospective, Demo, and Daily Scrum) http://learnsoftwareprocesses.com/2011/03/30/scrum-when-the-product-owner-finds-it-difficult-to-attend-the-meetings-sprint-planning-retrospective-demo-and-daily-scrum/ http://learnsoftwareprocesses.com/2011/03/30/scrum-when-the-product-owner-finds-it-difficult-to-attend-the-meetings-sprint-planning-retrospective-demo-and-daily-scrum/#comments Wed, 30 Mar 2011 18:34:02 +0000 ashish http://learnsoftwareprocesses.com/?p=784 This subject is probably one of the most debated and disputed topics in the entire discussion about Scrum. How many meetings should the Product Owner attend ? If you look at Scrum, there are these set of meetings: - Sprint Planning: In this meeting (or rather, extended meeting), the Product Owner explains the various User [...]]]> This subject is probably one of the most debated and disputed topics in the entire discussion about Scrum. How many meetings should the Product Owner attend ? If you look at Scrum, there are these set of meetings:
- Sprint Planning: In this meeting (or rather, extended meeting), the Product Owner explains the various User Stories that are supposed to be done in the given Sprint; further, this is the stage where the Scrum team actually breaks down the User Stories into the tasks, and then prepares estimates for these tasks, which are then allocated among the different members of the Scrum team.
- Sprint Retrospective: This is the meeting where the Sprint team looks at what they have done right, what they have done wrong, during the Sprint. When the Scrum team is fully involved with the process, they can always find areas of improvement, whether this be in terms of the process, User Stories, tracking, etc
- Sprint Demo: The team presents whatever they have completed in the current Sprint, and the Product Owner verifies whether this was what was intended and required. The Product Owner can decide whether the Demo was what is needed, can make changes, or even cancel what has been produced (in case there is a drastic change in the overall situation).
For the above meetings, the presence of the Product Owner is required; although there is a case that the presence of the Product Owner may feel that their presence is not really mandatory for the Sprint Retrospective. However, given that the Sprint Retrospective is a good way to figure out whether something is going right or wrong, as well as suggest improvements, it is important that the Product Owner attend this meeting. It is quite difficult to make suggestions about the improvement of the communication between the Scrum team and the Product Owner if the Product Owner is not there to attend. Hence, the ScrumMaster should work with the Product Owner to make sure that they attend these set of meetings.
There is something severely wrong if the Product Owner is not able to attend either the Sprint Planning Meeting or the Sprint Demo; if there is a case that the Product Owner is not able to attend, it would make sense to reschedule this meeting (hard to explain the User Stories if the Product Owner is not there; or have the Sprint demo if the Product Owner cannot make it there to the meeting).
If the ScrumMaster sees that the Product Owner is not regularly making it to these meetings, then one needs to raise this with the Product Owner (and other stakeholders), since the entire efficiency and success of the Sprints can be at a high amount of risk.

In the next part of this story, we will talk about the Product Owner and the Daily Scrum…

]]> http://learnsoftwareprocesses.com/2011/03/30/scrum-when-the-product-owner-finds-it-difficult-to-attend-the-meetings-sprint-planning-retrospective-demo-and-daily-scrum/feed/ 0 Scrum problem – When the Product Owner does not have enough time for detailing the requirements http://learnsoftwareprocesses.com/2011/03/21/scrum-problem-when-the-product-owner-does-not-have-enough-time-for-detailing-the-requirements/ http://learnsoftwareprocesses.com/2011/03/21/scrum-problem-when-the-product-owner-does-not-have-enough-time-for-detailing-the-requirements/#comments Mon, 21 Mar 2011 18:37:03 +0000 ashish http://learnsoftwareprocesses.com/?p=772 All those who work in a Scrum project are familiar with the concept of the Sprint Planning meeting where the Product Owner works through the various User Stories from the Product Backlog (reading off the prioritized list), details them out enough that the Scrum team can prepare estimates for these, and answers all queries that [...]]]> All those who work in a Scrum project are familiar with the concept of the Sprint Planning meeting where the Product Owner works through the various User Stories from the Product Backlog (reading off the prioritized list), details them out enough that the Scrum team can prepare estimates for these, and answers all queries that the team may have (and for complex features, or where there is a domain area that the team may not have much experience with, there can be a lot of queries that the Product Owner should be able to answer).
For all this, there is an expectation that the Product Owner has the details that the team is asking for. We had a case where the area was complex, and the team really went for all the various permutations and combinations. In many of these cases, we would normally ask the team to work through details as they went through the actual design process during the Sprint, but with the expectation that a lot of the basic queries would be answered by the Product Owner, enough that the team felt confidence that the Product Owner had a good grip on the User Story and this was not something that just came up.
So, in this specific case, we found that the Product Owner was so busy, when combined with the fact that the area of the project involved some complex business logic and user interactions; the team was not really happy with the amount of queries that got answered during their interaction with the Product Owner, and this was combined with the fact that the User Story as presented by the Product Owner just did not seem to have a good user flow. When this was clear, and the team also came up and gave up this feedback, there was some concern about whether this could lead to a substandard project being developed; we did some fact finding. When we queries the User Interaction expert, it became pretty clear that the amount of work that we expected would have happened between the Product Owner and the User expert had not happened to the desired level. When the User Story in terms of the simple workflow was shown to the User expert, the expert recommended that it needed some more discussion between the Product Owner and the User expert even before it could be presented to the team.
The next important question was about why the time was not being spent for this pre-Sprint activity. It turned out that the Product Owner was being assigned some additional work for some Product Management activity unrelated to the project (which was not budgeted for), and this was directly impacting the quality of the deliverable by the Product Owner. We got in touch with the overall manager of the Product Management team and got them to re-assign the work (which was for the organization, at a lower priority than the project) and we could see some noticeable improvements even within a couple of weeks.

]]> http://learnsoftwareprocesses.com/2011/03/21/scrum-problem-when-the-product-owner-does-not-have-enough-time-for-detailing-the-requirements/feed/ 0 A description of Scrum For Project Managers – some details http://learnsoftwareprocesses.com/2010/09/04/a-description-of-scrum-for-project-managers-%e2%80%93-some-details/ http://learnsoftwareprocesses.com/2010/09/04/a-description-of-scrum-for-project-managers-%e2%80%93-some-details/#comments Sat, 04 Sep 2010 20:03:47 +0000 ashish http://learnsoftwareprocesses.com/?p=663 The product requirements of Scrum are typically chunked into a small set called a Story, or feature, with a short narrative description, somewhat like a use case or a test case. When you talk to people who are involved in Scrum, you will hear the word ‘Story’ many times. Let us go into more detail [...]]]> The product requirements of Scrum are typically chunked into a small set called a Story, or feature, with a short narrative description, somewhat like a use case or a test case. When you talk to people who are involved in Scrum, you will hear the word ‘Story’ many times. Let us go into more detail of what a Story is. There are three types of stories namely: User Story, Technical Story and Bug Report. More details on each of these. A User Story describes what the user does with the software and how the software responds. A Technical Story is a non-functional requirement that describes the functionality supporting the user facing features in User Stories whereas a bug report is a description of the failure of the product to behave as designed and expected. Another important document in Scrum (one of the most important documents) is called – the Product Backlog; which includes all requirements not yet scheduled for implementation.
Another important term in Scrum is Sprint; in the old world, Project Managers call it the Schedule, but this is not an exact mapping. Small teams of 6-9 people work in short Sprints of 2-4 (the optimum Sprint timing is dependent on many factors, including the work to be done, the comfort level, etc) weeks to implement stories in rank order. In each of the Sprints the team members collaborate and self-organize; they also track progress and update tasks when finished. Team members collaborate to complete stories quickly instead of working on separate stories in parallel. At the end of a Sprint, completed stories are shipped: incomplete Stories are not. The schedule is not extended to complete work.
The three roles defined in Scrum are: the ScrumMaster, the Product Owner and the Team. The people who fulfill these roles work together closely, on a daily basis to ensure the smooth flow of information ant the resolution of issues. ScrumMaster is responsible for enforcing the process, tracking progress and expediting problem resolution. He keeps the team focused and productive, protects them from interference and ensures the swift removal of roadblocks. It is not required that a person like a Project Manager should be the ScrumMaster, you need a person who can keep the team moving, can understand the Scrum process, and can work quickly to resolve issues that the team faces. The Product Owner is the keeper of the requirements. He provides the single source of information about the requirements and their planned order of implementation. The Team is a group of people responsible for developing the product.
The different phases of development in scrum can be divided into three phases. During the first phase the SprintBacklog is defined and ranked set of requirements planned for implementation in a Sprint. Next is the turn of sprint planning meeting where the team estimates each Story in rank order. Next is the turn of task breakdown; in which identification of the set of tasks whose execution results in implementation of the desired functionality. Phase two consists of developing and testing of the Stories. This phase also includes monitoring and controlling which maps to updating the Burndown Chart and holding Daily Scrum meetings. Daily Scrums are daily status meetings to resolve issues proactively. An important practice of daily Scrum Meetings is that it is timeboxed to 15 minutes, which essentially means that questions are answered quickly; issues are identified and addressed quickly. The final final phase consists of Demo, Release and Retrospective. Closing maps to demonstrate the completed work in review meetings is done. The updated product is released and the Retrospective meetings held to capture the lessons learnt. At this point the cycle begins again. The next Sprint kicks off with the Sprint Planning Meeting using the updated ProductBacklog.

]]> http://learnsoftwareprocesses.com/2010/09/04/a-description-of-scrum-for-project-managers-%e2%80%93-some-details/feed/ 0