Sep 09
adminUncategorized
Looks like my team has some difficulties to observe a good daily scrum.
- Side chatters – I have to remind people that only 1 person at a time should be talking,
- Usually when the 3 statements have been announced, everybody engages in discussions – I have to remind them that it is not the time for such discussions and that if discussion is required, it should occur in a meeting following the daily scrum,
- Language problems – my team use Chinese for their daily scrum. I can understand part of it but not all. It makes it hard for me to manage problems. Also when i ask them if a meeting is required afterward, they always answer no. But I see them later gathering around a computer to discuss issues. Although this is not a problem, I’d like to be able to better keep track of the process.
Another problem is it is becoming difficult to keep track the tasks on the software. The wall is being updated all the time, but the Sprint backlog template I keep can hardly follow ….
Sep 07
adminUncategorized
Today we started the second sprint for this set of requirements… Again it’s only about bringing up a website accessibility using the w3.org requirements. This means that this is more like a Scrum simulation than a real Scrum. But still it does make the whole team understand and use Scrum which is good. But there are some serious drawbacks though. Amongst which:
- Requirements are not expressed as user stories
- More often than not requirements can’t be broken down into tasks
- Requirements are not expressed as functions
This has several consequences:
- Estimation is difficult and inaccurate, though this might be due our team’s inability to do proper estimate
- tasks are very small and not numerous … thus reducing the sense of urgency
- Scrum is heavy in comparison to the amount of work needed to achieve the Sprint objectives
With all this in mind, I still consider it as a success in the sense
- that the whole team is adopting Scrum successfully and enthusiastically.
- The management and development process suddenly became apparent to everybody in the whole company giving more sense to my role as well. Eventually, I sense that this will raise the whole department credibility thus my own credibility (I work as project manager but I am the only project manager, thus my role entails department management as well lol)
- Everybody is expressing himself more and gray areas are cleared early
There is still so much work to do to achieve a refined Scrum process…
Today however, we all discussed the concept of “Done”, we also started using some nice templates for our product and sprint backlogs and I also setup a quite nice Scrum wall… All this I feel is giving life to our process and bringing it one step closer to a professional high level Scrum process!
Sep 04
adminUncategorized
On our second day of sprint, I realise that most of the tasks are almost complete.
That has made me realise several things:
- The team is not good at estimating requirements, even only for 1 week work.
- If the requirements can’t be well broken down then it must be that the requirements actually are tasks…
- Estimating requirements does not make as much sense as estimating tasks for the team. If we had estimated the tasks during the task breakdown, we would have realised that the earlier estimate for the requirements were too generous. This would have given us a chance to revise all estimates and add more requirements to the backlog
Today is Friday, I am thinking of cancelling the current sprint and start a new sprint on Monday. Only a few tasks are in progress and most are in the verification stage. These could all be bundled in one requirement and be completed as a top priority item.
Scrum rocks!
Sep 03
adminUncategorized
Today I just setup our first Scrum Wall! YEA!
I started by putting big white pages on top to separate sections.
Then I started to put post-its for all the requirements and the tasks…. All left in the “not done” section
Then I asked all my team members to go to the board and by themselves move their tasks around!
That was cool! and after 1 day of work, the tasks have been moving quite a lot…
Observation:
Almost all tasks have already been checked out and most are laying in the “To be verified” section. Looks like this sprint has largely been overestimated.
Sep 03
adminUncategorized
Following the sprint planning, we had the task planning.
Starting time: 1000
Finish time: 1040
Attendees: Kevin, Nic, Cherry, Ronan, Kathie, Bill, Matter, Lele. The team is complete
Objective: break down all requirements into tasks. Ideally each requirement should have about 5 tasks.
All went globally well except that I forgot to make them estimate each task in term of hours.
Observations:
- The fact that 2 members were not present during the Sprint Planning was a great problem as this brought disagreements amongst the team members, we had to clarify some requirements again
- The team could hardly come up with good tasks for a given requirement. The fact that the requirements were not true user story seems to be the reason. The requirements in this case were too granular already.
Sep 02
adminUncategorized
Today we had our first Scrum Planning.
Just a few days ago, my client came to me and said: “We need you guys to make our website accessible” and he passed down a list of requirements from W3C. Very nice list I thought and I thought: “Ok let’s do our first SCRUM using this as a product backlog”. It’s not big but it’s not too small either especially because the client’s website is pretty big.
The first thing we did was start the Sprint planning.
Start time: 1345
Finish time: 1810
Attendees: Kevin, Nic, Cherry, Ronan, Kathie, Bill. 2 members could not join because they were busy on other projects.
First thing, set the Sprint Objective. After some discussions, nobody could really come up with something and we just wrote: Implement one full page of requirements… lol
Second thing was to review all the requirements one by one so everyone gets a good understanding… wow that took long time, and it was difficult.
After that, we went through the list of requirements again and we played poker to do the estimate. That again took a long time. The conversation too often diverted in some technical considerations of how it was going to be done.
Finally, we drew the line and decided how much we would accomplish for this sprint.
First observations:
- if possible team members should review all requirements beforehand
- the product owner needs to prepare very well designed stories: as {user type}, I wish to {task details} in order to accomplish {objective}
- Next time I think we will all review the requirements first before the meeting, and we will go straight to planning poker
- Some lower priority tasks were not estimated because too much time was already spent and we could not afford to continue the meeting any longer
- Planning poker is excellent. It helped team members get a better understanding of the tasks, as well as uncover misunderstanding leading to diverging estimation, as well as help build commitment in the whole team
We decided to push the Task Planning to the next morning.
RSS