4

I'm starting a one dev project (me) and it's going to be a short one (Approx. 4 weeks).

In such a short term scenario, I still went through the requirements with the Product Owner (PO), prepared all the user stories, and setup a board.

A first prototype will be released in 2 weeks, and the final release in 3 weeks, with an additional week for user training and some bug corrections.

As it always happens with these things, having a full backlog growing throughout this phase, will hopefully identify some requirements for a potential Phase 2.

For the estimations, it being a one man job, I just went with T-Shirt sizes to make it easier for everyone to understand.

Now that I've described my scenario, here go a few questions:

Would you still go through the exercise of having the PO giving a business value to all the stories, knowing that at least 90% of them at this stage are absolute must have, or would you leave that for whatever remains pending after the first prototype?

Also, any comments,suggestions or best-practices references you might have for such micro-scenarios, would be greatly appreciated.

Thanks, JC

Improve this question

5 Answers 5

Reset to default
1

You are in a short project, and that too a solo one. For this situation I would eliminate most of the overheads that are usually there in an agile project.

Here are the changes I would do:

  • Estimation (even T-shirt) is not required, since you aren't going to be doing any long term planning. It's just a one month project, the schedule is fixed, scope is limited, so the estimates are not going to help you in any meaningful way
  • Assigning numbers to business value is too much overhead. Talk with the PO instead
  • Do get the backlog in order of importance. Even if you plan to complete everything within one month, things happen and you may not be able to do so. It is critical that you do the most important stories first
  • Be in constant communication with the PO. It doesnt matter if your code is not complete or not releasable. Show your results daily if possible and incorporate the feedback.
  • There is no need to have formal sprints, and sprint planning, and formal demo sessions. You can be doing the equivalent of daily sprints. Plan for the day, build something, show the PO in the evening (or every couple of days) and repeat.
  • Get a piece of chart paper on the wall, write your backlog on post-it notes, stick it up. This is your PM tool.

Overall, I'd suggest a very lightweight process as shown in this video

Improve this answer
1

Would you still go through the exercise of having the PO giving a business value to all the stories, knowing that at least 90% of them at this stage are absolute must have, or would you leave that for whatever remains pending after the first prototype?

A backlog of prioritized stories typically means that you do pick up as many as you can complete within the release cycle or iteration. In other words your scope is (somewhat) flexible as you may not be able to fit all of them.

On the other hand you say that 90% are "absolutely must have". In other words your scope is fixed (at least for those 90%).

In my experience you can't have both, flexible scope and fixed scope. ;-)

To resolve this I would suggest the following approach: For any pair of stories ask the Product Owner (PO) which one she/he would want if she/he can have only one of them. That way you don't need the business value for each of them but you still get a relative priority based on business value as perceived/estimated by the PO. Then see how many you can complete in the release cycle and tell the PO. Alternatively you would look into other options (reducing scope, extending timeline, adding a second person).

Improve this answer
2
  • I like the idea of picking a pair of stories and get their relative priority. Still unsure about timing. When I say must have, I'm talking login level equivalent, to give you an idea of how basic this stuff is for this particular process. But as new requirements come in, I'm trying to think of ways to protect myself from scope creep. If i ask her to prioritize now, the answer will be, "I need everything" If i wait for a few more stories to come in, it will probably be easier to explain the need for priorities, and then justify asking for more time/resources. Transparency vs Bus Proc engagemnt
    – Jorge Carvalho
    Oct 21, 2011 at 1:06
  • In release cycle or iteration you can fit only so much work, e.g. story points or whatever you use. If new requirements come it, you can card them, size them and run again through all cards that haven't been started yet. The product owner can then prioritize them including the new cards. As long as the overall size/capacity for the iteration isn't exceeded you are fine. The scope for the iteration is not bigger but may be different.
    – Manfred
    Oct 21, 2011 at 22:32
1

Frankly I've never been a big fan of having a PO assign "business value" points to stories. If you desire to place such a number on a card I would recommend doing it at the "epic" level.

Why you ask? First lets look at why you would want to put business value on a story:

  • to be able to measure the amount of business value delivered to a customer or organization
  • for prioritization at sprint planning meetings when you can compare the value of each story and its cost against one another

Now, lets look at why I think its a waste of time to assign business value at the story level:

  • The value of a small deliverable is quite often seen as the value of the entire project. For example let's say you were building a boat for a PO. What is the value of the propeller? Well, the customer doesn't want a boat that doesn't have a propeller so its value is that of the boat.
  • Assigning value to small stories or features (often which are intertwined and occasionally have dependencies) is often quite difficult and time consuming to put a value on.

Assign business value to your epic's / core features. From their you can break down the "high value" epics into stories & plan accordingly into sprints (as you have already done).

If you wish to read a little more on business value and stories, here is one of my favorite all time blog posts: http://blog.nayima.be/2009/12/30/how-do-you-estimate-the-business-value-of-user-stories/

Improve this answer
1
  • That's a good point. I guess I could look at this initial backlog as one single epic. Just get the boat going. As the requirements start coming in about having leather covers on the seats, and having a dolphin painted on the side, then start worrying about priorities. Still in line with John's answer: No business value number.
    – Jorge Carvalho
    Oct 21, 2011 at 1:16
1

Would you still go through the exercise of having the PO giving a business value to all the stories, knowing that at least 90% of them at this stage are absolute must have, or would you leave that for whatever remains pending after the first prototype?

Make sure you know which 90% are the must haves. Anything beyond that is not necessary in this case.

Also, any comments,suggestions or best-practices references you might have for such micro-scenarios, would be greatly appreciated.

Since this is one man show, I'd use a simple personal Kanban to track stories with WIP limits on development and testing. On such a short schedule there really isn't time for the traditional ceremony of iterations but you still need some way of providing structure to your work to make sure you're moving in the right direction. Something like the AgileZen board would even calculate some metrics to help you make adjustments as you work.

Improve this answer
0
0

Would you still go through the exercise of having the PO giving a business value to all the stories, knowing that at least 90% of them at this stage are absolute must have, or would you leave that for whatever remains pending after the first prototype?

Also, any comments,suggestions or best-practices references you might have for such micro-scenarios, would be greatly appreciated.

For stories with real end user value, you absolutely should go through the business value process. It's not the BV number that matters. What matters is that you and the PO and hopefully the customer are talking about what is and is not important. Assigning BV is one tool used to facilitate that conversation.

Best Practices:

  1. Agree with the PO what a story is and is not. Tiny details are probably best left as tasks in the appropriate story. Stories should have no dependencies on other stories and should be potentially releasable.
  2. Work hard to keep the number of non-user value stories to a minimum.
  3. Agree with the team (you, PO, customer) on the iteration length. In a project lasting only one month with one developer, you might suggest daily or weekly iterations to keep communication agile. Remember, agile typically suggests a daily stand-up with other developers that allows the PO to listen. Having a daily stand-up with you and the PO will allow you to focus and allow the PO to see progress.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.