Learn Software Development » Requirements

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

What is a MVP in terms of software product development ?

ashish — Wed, 07 Dec 2011 19:54:18 +0000

A lot of have people have not heard of the term called MVP. The full form of MVP is called Minimum Viable Product, and represents the set of features that is believed to be essential for the release of a product. The use of MVP is a strategy that decides the number of features that should be built into the product, just those set of features and no more. I will describe with an example as to how the MVP was used to drive the discussions about the list of features that should be part of the product version, given the compromises that need to be made with regard to the availability of resources, the time available, and the need to have features for the release.
Consider a case where a new version of the product needs to be released, and there is the familiar discussion about the feature list that needs to be approved for the product version. The product management team could come up with a large number of features, but that is just the starting point. The features need to be arranged in a prioritized set of features, associating them in terms of the most important, the ones that are somewhat less critical, and the ones that are good to have. This activity can take a fair amount of time, since the product management team has to balance the need for a feature in terms of meeting competitive pressures, in terms of getting good reviews (the initial set of reviews generated by professional reviewers in tech blogs and magazines), and being useful to customers, since that generates the overall positive buzz among customers in various tech / software related forums.
Once this priority has been set for the features, these features, especially the most important features, need to be set in terms of the MVP for the release. Getting such a list of features without which the product will not ship helps guide the discussion beyond this point. Thus, once the Product Management has set out a list of features that need to be done for the product to ship, and have convinced the stakeholders including management and the engineering team about this, then the rest of the discussion is about how to meet the MVP.
If the timeframe or the number of resources are not enough to get the feature set as defined in the MVP done, then the discussion moves towards debating the timeframe, as well as the number of resources available to the engineering team. In our current case, the number of features in the MVP were not being met, and the release was critical, hence the team got authorization for an increase in the number of engineers so that the feature set could be met. This was not possible until the must have feature set was defined, these forming the MVP.

Problem – When stakeholders disrupt the prioritized feature list of items for a Scrum team

ashish — Wed, 09 Nov 2011 19:14:50 +0000

When you start working out some of the basic assumptions of how a Scrum team is supposed to work, one of the base assumptions is that the Product Owner sets the priorities of all the features / User Stories for a Sprint. Now, depending upon business needs, this order can even be changed midway during the Sprint (should be avoided in most cases is what most of the literature says) if there are pressing needs to change the priorities. This can also be done by ending the current Sprint at the point where the decision to change the Sprint Backlog is made, and starting a new Sprint (which can be set to end at the same time as the previous length of the Sprint).
However, this becomes a problem in the case of service teams. Consider a team that prepares some kind of infrastructural work for other teams; in this case, the User Stories are derived from the needs of other teams, but controlled by a Product Manager who decides the priority for the requests coming in from other teams. This can be quite problematic, since other teams all have their own priorities, and the Product Owner can have a difficult time just trying to balance the requirements of the other teams. If the team is lucky, the requirements of the other teams can be somewhat similar, which makes the work of the Product Owner easier.
I have also see a case where the Product Owner had a really tough time, having to fend off a number of pushes from the different stakeholders that impact the work. So, the Product Owner decides the User Stories based on some inputs, and sets the Sprint Backlog for the defined interval. The team starts work.
And then the pressure starts. Another team suddenly finds that their external environment has changed, and decide that they need something fairly quickly from the infrastructure team. The team finds that the external stakeholders are applying additional pressure and the pressure in this case can rise to such an extent that the team is forced to change their User Stories midway during the Sprint. Once in a while, a team can endure this and understand this, but if this pressure and change in Sprint features keeps on happening, the team starts questioning their implementation of Scrum and will suffer reduced morale. However, it is not realistic to assume that the Product Owner can easily overcome the external stakeholder pressure.
I do not have a good solution to this one, and did not have one when the ScrumMaster of the team asked for opinions.

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.

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.