Learn Software Development » Product

Scrum – Provides you a good quick feedback on accuracy of estimates for tasks ..

ashish — Sat, 10 Dec 2011 21:24:28 +0000

One of the major dependencies for a successful project schedule is in terms of the accuracy of estimates versus the reality. In short, you want to measure the difference between the time estimate for a project (or a task inside the project), and the actual effort needed. For such a measurement, you would want to ensure that variables such as changes in feature specs or design between the estimate and the actual execution are eliminated; if your design changes between the initial estimate and when you sat down to do it, then it is very difficult to make such a measurement, or to learn something from such a measurement.
Consider the following example; a colleague of mine used to review the actual time spent on a task, and then compare it with the estimate for the same. He used to do this for multiple tasks, and where the variables (such as requirement changes, or design changes, etc) did not change too much during the time period, he would slowly start to learn which person tended to do the task earlier than the estimates given by the same person, and also the reverse. The next time he would ask these people for an estimate, he would accordingly make the relevant changes in the estimate he got, and then use the modified estimate for the final planning.
Scrum makes this review even more easier. In Scrum task tracking, the team is supposed to provide an update every day on what has been done, and which tasks will take up more time than initially planned. As a result, and especially because tasks tend to be defined in terms of hours and a few days rather than 5+ days, it becomes immediately clear as to which tasks are getting delayed. So, when you are using Scrum in your team, you will immediately start to see the variance between estimates and actual figures. Now, the development team may think that you are trying to find fault, but getting the estimates to be as close to actual figures is very important. This helps you better estimate the deliveries at the end of the Sprint, and prep the customer / product owner about what all is going to be delivered for which you want feedback. This also helps stakeholders get more confidence in the work done by the team.
Being able to see variance could also help you to figure out more research into why the estimates are getting varied; is it because the details provided by the Product Owner are not detailed enough to generate the right estimates, or is it because there are some design issues that cause more effort than people estimate. Make sure that this investigation is done.

The Elements of Scrum

The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper

Practical Software Metrics for Project Management and Process Improvement

How to define tasks for a User Story without spending a fair amount of time on these ?

ashish — Sun, 30 Oct 2011 18:56:46 +0000

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.

How to incorporate UI design as part of Scrum work, collaboration between Product Owner and UI Designer

ashish — Tue, 18 Oct 2011 19:16:37 +0000

If you want to ensure that your product / software application is successful, there are a number of things you need to care of. If you look at the success of many of Apple’s products such as the iPod, the iPad, iTunes, and the iPhone, it is about ensuring that your workflow appeals to customers, that they find using it so easy that they are even willing to pay a premium for such products. What this brings out is the importance of ensuring that you have workflows that appeal to customers, and this means that you need to get your UI designer into the product development process. However, it is not easy to integrate the working of processes with the working style of UI designers. In my experience, getting them to work with the kind of deadlines and schedules that you can impose on engineers and QE can be a difficult task, and this process can interfere with their creative juices.
So, what happens in the case of Scrum ? Well, for Scrum work, we typically say that features should be worked upon when you get close to the Sprint, since that is when the prioritization of features for a Sprint actually happens. However, when the sprint starts, the team starts working on the tasks, which means that the UI for those tasks should be ready. Which automatically means that the UI for tasks should start before the Sprint planning activities (seems a bit strange that some activities for tasks should occur before the Sprint in which the task should be worked on, but there is no other way to get the UI in place).
For this to happen, it is also necessary that there is a parallel planning process underway, whereby the Product Owner has a list of prioritized tasks (already there as part of the Product Backlog); with the difference being that the tasks for the next Sprint should be confirmed during the previous Sprint. In addition, there should be a schedule in place which tracks the work being done by the UI designer, and this planning needs to happen with the Product Backlog, so that it should never happen that the UI designer is getting too many tasks. If this happens, then the UI will not be ready when the team is starting work on the tasks in the Sprint.
So, in the Sprint before a particular Sprint, the Product Owner, one or 2 assigned team members, and the UI designer should be working on a list of tasks for which the UI is required at the start of the subsequent Sprint, and should aim to get a high level workflow document and a UI wireframe in place. Once the actual Sprint starts, the Scrum team will start working with the UI designer to get the final UI based on the User Stories outlined by the Product Owner.

Discord between the Scrum team and the Product Owner on the feature list priority

ashish — Sun, 16 Oct 2011 19:15:14 +0000

This particular post is more of an opinion rather than a stated part of the process (as far as the discussion that I have had with several Scrum Masters has led me to believe). The Scrum process outlines a role for the Product Owner to define the features of the product, and also to determine the Product Backlog (the prioritization of the features that will be part of the ongoing Sprints). At the same time, the Scrum team is an empowered Product team that needs to take up a much enhanced responsibility for the tasks that make up the features, determining the efforts for the various features, and so on.
So where does the challenge come ? Well, the challenge comes with a team that feels much more empowered, more responsible for the features that go into the product, its feature set versus the competition, the needs of the customer and so more. Teams that have taken on more responsibility typically have people who look at customer forums, who interact with customers to get more in touch with their needs, and similar such measures that bring them closer to the customers and their needs.
This has the potential for sparking a conflict, such as when the Product Owner (based on their own research, contacts with customers, and studies of the market) places a few features as higher priority; and then you have team members, who believe that they know the needs of the customer, coming into some sort of conflict with the Product Owner. Now, you would expect that the Product Owner is the one who decides the priority of features and the details of the feature, but when you get a team to become more responsible for the features, get them in closer touch with customers, then they will start to become much closer to the future vision of the product; so if what the Product Owner is saying does not gel well with them, then there will be some sort of opposition. This opposition can make itself known during the Sprint planning meetings, as well as during the Daily Scrum meeting when the team may have some query on some part of the task, and the approach suggested by the Product Owner may be resisted.
Is this a theoretical position ? No, we have had cases where the managers of the team members have to get involved, in order to better understand the position of the team members, and then counsel (and where required, have a quiet word with the Product Owner). Once in a while, we thought about letting such an open discussion happen, but the thought was that such a discussion would undermine the position of the Product Owner and was not the right step to take.

Scrum – What can happen when your Product Owner is a big picture guy and really does not get into details

ashish — Fri, 15 Apr 2011 09:16:38 +0000

If your Scrum team is in such a situation, you are in fairly big trouble. We had a case come to us from another organization where the Scrum team was in deep trouble and was starting to raise a number of issues – over their first few Sprints, it was found that the team was not able to meet their estimates for a large chunk of their work; it was hard to compare their velocity and capacity, and overall, their larger stakeholders were starting to raise issues about the performance of the team, and the Product Owner was adding to the din.
What was happening was that the Product Owner was another of those people who did not really get into the Scrum training Program, who felt that it was his job to get the overall industry scenario and what the customers wanted, but a lot of this was at a high level. The Product Owner was very well recognized in the industry and was well known for his connection to the customers, and for being able to stay ahead of competitors in terms of what the customers wanted.
However, the biggest problem with this guy was in terms of his abilities of directing working with an engineering team in a Scrum model. So, the Product Owner did not really get into details of the User Workflow, the different scenarios that come in when you start working out the actual different workflows that can happen. If you were to ask the Product Owner about what would happen in Scenario 1 vs. Scenario 2, and in other scenarios, he would getting blank, and expressing statements that he is there for the big picture, not for getting into these details.
What made all this problematic was the fact that the Product Owner would take this same attitude in the Sprint Planning meeting. When there came a time to explain the details of the User Stories and answer questions so that the Scrum team could estimate, the Product Owner would claim that he had not worked through the details (and the Usability Designer had the same attitude since the Product Owner would not have done the required amount of working through the details).
As a result, the team was finding it very hard to do an estimation of the tasks, and as a result, at the end of every Sprint, the team would find that their progress was not predictable, that tasks that were supposed to be done in the Sprint were not getting done, and so on. After a couple of Sprints, the team decided that this was badly affecting their effectiveness, and took this up with the Scrum Master, and wanted to see some action. It was hard for the Scrum Master to take some action, since this was a senior Product Owner; but since this affecting the team, something needed to be done. As a result, this was taken up with the stakeholders, and finally decided that an Associate Product Owner was needed to actually work between the Product owner and the Scrum engineering team to break up the User Stories into tasks, and provide the details that the team needed.